Chris Garty's Weblog : Testability

Behavior Driven Development

chrisgarty — Tue, 04 Dec 2007 04:00:00 GMT

At the last Fargo Moorhead Developers meeting we had a great presentation from Max Pool about Behavior Driven Development. It sounded strangely like TDD. After the meeting I jumped online and researched it some. I wanted to post the links and important excerpts that provided me the most insight into this concept:

Dan North - Introducing BDD

http://dannorth.net/introducing-bdd

...

I started using the word “behaviour” in place of “test” in my dealings with TDD and found that not only did it seem to fit but also that a whole category of coaching questions magically dissolved.

...

I found the shift from thinking in tests to thinking in behaviour so profound that I started to refer to TDD as BDD, or behaviour- driven development.

...

Wikipedia

http://en.wikipedia.org/wiki/Behavior_driven_development

...

Behavioral tests use the techniques of Test-Driven Development but have a more specific goal. The purpose is to define the behavior of an application rather than the implementation.

...

Testing before implementing is a crucial aspect of Behavior Driven Development.

...

Behavior Driven Development

http://behaviour-driven.org/

...

It must be stressed that BDD is a rephrasing of existing good practice, it is not a radically new departure. Its aim is to bring together existing, well-established techniques under a common banner and with a consistent and unambiguous terminology. BDD is very much focused on “Getting the words right” and this focus is intended to produce a vocabulary that is accurate, accessible, descriptive and consistent.

In fact “Getting the words right” was the starting point for the development of BDD, and is still very much at its core, but the power of getting the words right has led to some insights and extrapolations that have helped us to better understand our approach and to extend it.

...

NSpec

http://nspec.tigris.org/

...

Test Driven Development isn't brilliantly named, it hides the fact that TDD is a specification process, not a testing process.

...

BDD and NSpec have shed the test oriented terminology in favour of a specification friendly nomenclature.

...

[Context]
public class Example
{
[Specification]
public void BooleanSpecificationExample()
{
Specify.That( someObj.SomeMethod() ).ShouldBeFalse();
//...

...

NBehave

http://nbehave.org/

...

Behaviour-driven development (BDD) is an evolution of test-driven development (TDD) and acceptance-test driven design, and is intended to make these practices more accessible and intuitive to newcomers and experts alike.

...

It shifts the vocabulary from being test-based to behaviour-based, and positions itself as a design philosophy.

...

Dan Pink (author of "A Whole New Mind") has coined the phrase "A metaphor can be worth a thousand pictures". My memory isn't that great so I like to distill things down to a concept or metaphor. BDD is all about getting the words and metaphors right. It is a language that I'll take a while to get used to, but after doing my best to explain TDD numerous times I can see the advantages of the behavior metaphor over the test one.

I'm really interested in using the specification language that Dan North was talking about... I'm going to have to give that a go...

Ward Cunningham on Patterns and XP

chrisgarty — Thu, 09 Dec 2004 10:21:00 GMT

Ward Cunningham recently did a great interview with TSS.Net. In the interview he talks at length on some great topics including XP, patterns, team development, communication, simplicity, testing, and feedback.

If you haven't seen it already, it is definitely worth the bandwidth. It is available in two sizes for 56k or DSL

Spring has arrived!

chrisgarty — Tue, 05 Oct 2004 19:42:00 GMT

In the land down-under, it is springtime. The birds are chirping louder, the days are getting longer, and the sun is getting hotter. I even got sunburnt playing soccer on Sunday :).

And for .Net developers Spring in another form has arrived in joyous splendor... Spring.Net 0.6 RC1 has been released.

The arrival of Spring.Net gives .Net developers another solid choice on the road to more loosely coupled component-based systems. Spring.Net will soon be MUCH more than just a lightweight container, but even just as a lightweight dependency injection container it is an excellent offering for the .Net development community.

Martin Fowler’s recent article on lightweight containers and dependency injection highlighted two excellent Java offerings; Spring and PicoContainer. Now both of these alternatives are available to the .Net world.

Whether you use a dedicated dependency injection container like PicoContainer, a service locator offering like .Net's own System.ComponentModel namespace, a pluggable model like the provider pattern, or a dependency injection container ‘with more’ like Spring.Net the important goal of separating configuration from use during .Net software development has never been more widely supported or easier to achieve.

Dependency Injection: World changing concept or nothing special?

chrisgarty — Thu, 19 Aug 2004 09:23:00 GMT

That was the question that I got asked about a month ago. My response was "something in the middle". I like Dependency Injection. It facilitates testing, it facilitates change, and it facilitates clean design.

I have been thinking about container assisted dependency injection lately and have been playing around with PicoContainer. I've been trying to justify the use of PicoContainer to facilitate dependency injection versus just injecting dependencies manually. My primary aim was to facilitate testing and good design, so the manual passing of dependencies was sufficient, but there was this nagging voice in my head telling me that the design would be more open to change if the rigidity of the dependency injections was placed in just one spot. However, I couldn't quite articulate that idea and had just left it hanging for a little while.

Enter Mr Oberg.

Rickard Oberg is a very smart guy that I first found out about when he did an interview on TheServerSide.com back in 2001 when he was a core architect and developer on the JBoss (then version 2.0) J2EE server. Rickard has made some great posts on his blog over the past year that have helped me better understand Aspect Oriented Programming (I'm watching the development of Spring.Net with some interest) and the value it can bring to software development.

Rickard just made a great post on "Dependency injection and open vs. closed designs" that has helped bring clarity to my thoughts on dependency injection and design. Go read his post for the full story, but I had a number of 'oh yeah' moments while I read this part:

So, is an "open design preferable to a "closed" design? Well, I like to compare this to house building. Using a "closed" design is like building a house where the rooms have no doors. Whenever you decide that there needs to be a door between two rooms you punch out the wall and insert a door. It's not something you would do easily. On the other hand, using an entirely "open" design is like building a house where the rooms have no walls, only doors. This makes for great flexibility, but don't be surprised if the roof comes crashing down. The conclusion of this analogy is that you'd probably want both: the rigidity of walls combined with the flexibility of doors. In Pico terms, the foundation of the house is provided by the Container, while the rigidity is provided by a ContainerComposer. The composer is the place where all decisions are made, and essentially it has to know about all the things that Foo knew in the "closed" design version: whether Bar is a class or interface, how to instantiate Bar, and what parameters to provide to it. If you let it do this for all components in the system, then all of our assumptions have been put into one place, and if any assumption would be wrong, that is the only place which would be affected by it.

Got it?

Dependency injection = 'open'. Specific injection decisions = 'closed'. Pico + ContainerComposer = isolate the 'closed' parts in one 'easy to maintain' place. Biggest value of a Dependency Injection container = maintainability.

Got it.

Presentation: Agile .Net Development - Part 1 - Tools and Basics

chrisgarty — Wed, 30 Jun 2004 21:18:00 GMT

Last night I gave a presentation at the Melbourne Agile Developer Group (MXPEG) about agile .Net development. The group has a higher proportion of Java developers, so I had volunteered to give a view of agile from a .Net perspective.

I only got through half of my material last night, so I'll be talking again next month. Last night I presented information about a set of tools that can help if you are trying to follow some of the Extreme Programming practices while using .Net. Next month I'll be focusing on design decisions in .Net that have helped me create applications with a simple and testable design.

The practices covered were: Coding Standards, Continuous Integration, Refactoring, and Testing.

The technologies covered included: NUnit, NUnitAsp, NUnitAddin, NMock, PicoContainer, FxCop, CruiseControl.Net, NAnt, NCover, and Microsoft's yet-to-be-released Visual Studio Team System.

The presentation is available here.

VSTS: Getting coded web tests to run

chrisgarty — Fri, 04 Jun 2004 19:23:00 GMT

The coded web tests supported by the VSTS test tools really excite me. There are so many web test scenarios that I can now create very easily with a combination of recording and scripting. This will nicely complement the ASP.Net testing capabilities I already have thanks to NUnitAsp.

However when I recorded a web test, generated the code from the test, and then tried to use that test the test runner wasn't able to load my assembly. It gave me an error similar to this:

WebTestCoded Coded Web Test Error Could not run web test 'WebTestCoded' on agent 'MyComputer': Could not create instance of class 'WebTestCoded' :File or assembly name 'WebTestProject1, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null', or one of its dependencies, was not found.

So I jumped on the Microsoft newsgroups and just got a reply to my query: You have to copy the assembly to VSDIR\Common7\IDE\PrivateAssemblies.

To help with this process, add a post build event similar to the one below to all projects with coded web tests: copy WebTestProject1.dll "C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\PrivateAssemblies"

Thanks to Eric Adams (PM - VSTS Test) for this solution!

Safer C# Constructor-based Dependency Injection with readonly

chrisgarty — Mon, 31 May 2004 23:25:00 GMT

Most people would have used the const keyword while doing C# development, but I had never heard of the readonly keyword before. Well, this weekend I had a friend point out this keyword and the first usage that came to mind was constructor-based dependency injection.

Here is the clarification of the differences between readonly and const from MSDN:

The readonly keyword is different from the const keyword. A const field can only be initialized at the declaration of the field. A readonly field can be initialized either at the declaration or in a constructor. Therefore, readonly fields can have different values depending on the constructor used. Also, while a const field is a compile-time constant, the readonly field can be used for runtime constants e.g. public static readonly DateTime _creationTime = DateTime.Now;

So now I can create a class with a dependency (reference) that is injected in the constructor and I can be sure that no method in the class will change that injected dependency.

Using Martin Fowler's MovieLister example, I can now have this:

public class MovieLister
{
    private readonly MovieFinder finder;
    public MovieLister(MovieFinder finder)
    {
        this.finder = finder;
    }
}

And if anyone tries to change that readonly local member variable in a method like...

public class MovieLister...
    public void MethodThatWontCompile()
    {
        this.finder = null; //Error because a readonly field cannot be assigned to
    }

...they'll get an error on compilation: 'A readonly field cannot be assigned to (except in a constructor or a variable initializer)'

So in summary, the readonly keyword provides us with a facility for ensuring that our constructor injected dependencies are not tampered with by other methods in the class.