TDD (Test Driven Development) is an amazing Software Design and Development methodology that revolutionises the way that you build Software.

When Doing TDD you are trying to Isolate your SUT (System Under Test). To do this you typically create Test Doubles (see previous blog) either automatically with a tool such as RhinoMocks or manually (i.e. you hand code the TestDouble).

Peer programming with an Intermediate today and I called my Test Double a xxxxSpy. My Peer immediately asked me why? I quickly ran a survey with several friends who all do TDD and realised that the difference between different types of Test Doubles is not well understood.

Since I am a believer that a common language helps communication I decided to quickly write this blog. It mostly contains references to other peoples excellent writtings on these topics.

Learning to write good tests can be hard. There are a lot of things to learn technologies to master and if you have been programming for some time then there are some bad habits to undo.

I train a lot of people to do TDD and have learnt from this that there a few small tricks that will significantly help you write a good test.

This blog assumes that you are familiar with the Red, Green Refactor process of test driven development and have some exposure to a unit testing framework such as NUnit.

I also assume you are familiar with the concept that TDD is not a testing activity but is in fact a design and development activity.

In this blog I go through the parts of what I consider to be a good test.

So, we are starting to develop a project in an Agile, TDD manner and we don’t really want to be concerned with too much other than this object has this property and relates to some other object... because my test that I’m currently writing needs it. I don’t really care how this fits into the whole scheme of things at this stage. The fact that my “Invoice Line” object can only ever exist on an “Invoice” and that the invoice must be associated to a “Customer” in order to be valid doesn’t really concern me at this stage. Although all those other facts are true, they have no relevance to my SUT (system under test)...

Changing the Return Value of a Stub in RhinoMocks.