Canned Objects

Canned objects are fantastic to use in situations where you want an object to respond with a predefined value or you don’t care what the response is as it doesn’t directly effect your test. It responds with the same value no matter how many times I call it. I use these objects most extensibly in my testing, especially for repositories. I only have one canned fake object per real object, except when I have services which, eg do validation; in this case, I create NegativeValidationService and PositiveValidationService objects to help readability of tests.

public class CannedBookRepository : IBookRepository
{
    private IBook book;
    public CannedBookRepository(IBook book)
    {
        this.book = book;
    }
    public CannedBookRepository() : this(new BookBuilder()) {}

    public IBook Find(IKey bookKey)
    {
        return this.book;
    }
    public void Save(IBook book) {}
}

Stubbed objects

Stubbed objects are fake representations of their real counterparts, and as such will tend to emulate their behaviour. The main difference, however, is that they do not talk to expensive services, eg database connections. I use stubbed objects mainly when I need my fake object to reply in different ways for different inputs, or when testing that I can put an object into a repository and will access an identical version of it. Again, generally I have at most one per real object; I usually don’t use them.

public class StubbedBookRepository : IBookRepository
{
    private IList books = new List;

    public IBook Find(IKey bookKey)
    {
        return this.books.Find(book => book.Key.Equals(bookKey));
    }
    public void Save(IBook book)
    {
        this.books.Add(book);
    }
}

Mocked Objects

Mocked objects make use of existing mocking libraries, such as Mockito, Rhino mocks or mocha and are used mainly to test either that the correct method has been used for an API or when testing legacy code (ie when they have used static methods/classes and I cannot change that – TypeMock can do weird stuff with statics).

Why

The main reasons why I prefer these fake objects, as opposed to using a mocking library to stub certain methods are:

• it is less lines of code in the test (only by declaration) – there are no setup, stub, replay/verify calls. All setup is done in the constructor
• it is more maintainable – resharper can refactor it easily. Also if the methods are being refactored, eg changing a bool return type to an enum there is a single point of failure
• it is easier to read (imho)
• I don’t have to worry about different syntax when creating real and fake objects – they are created in exactly the same manner. This also helps testing, as usually they are not the main concern of the test
• once created, they are always there to be used
• they help drive out design – if I find I have a fake object with many methods which throw the NotImplementedException, I can begin to ask “Are all these behaviours on the correct object?”

To summarize: canned fake objects are cool.

Traditionally, any new functionality is vetted by a software architect who completely designs it (on paper) and sometimes adds the foundation to the code base. The developers in the team then take the designs and implement them, sometimes in a cookie-cutter fashion. The developers often don’t understand the design (at least why it is in the form that the architect has specified) and when they start to query it get negative reaction from the architect.

The question is, if we now say our tests will drive out design, where does the architecture go? Won’t this just lead to a micro-optimisation, without anyone looking at the system as a whole. Chaos!

In my mind, the role the architect plays in this brave new world is to provide the team with a 50000-ft view of the system. The architecture declares that MVC will be used, how the infrastructure is strung together, but it does not specify which classes will be created, what services will be used and what design patterns will be used. These are really implementation details, and are the elements which are driven by your tests.

Other XP and agile principles will also help with ensuring your newly TDD code base does not turn into chaos. If you adopt a domain driven design approach, then your business layer and logic will be driven out by the business and you will know from that which classes need to be created, what should be a service and what are your repositories. If you adopt pair programming, then the ‘architects’ experience can be shared with other team members and the knowledge of what constitutes good design increases, lessening the role of the architect. 

So, how does Architecture fit into TDD? Quite nicely, I think.

A: What are we trying to test

B: The instrument controller

A: Ok, what is it meant to do

B: Well, we are going to send it an instrument and its going to go to the Songs table in the database and query it for songs which use that instrument and then its going to render them on the page

A: Hmm – that sounds like how. What is it meant to do?

B: Umm – find the songs that use the instrument and display it on the page.

A: That sounds pretty good. Except is it responsible for displaying it on the page or is that the responsibility of the view object?

B: Yeah – the view object actually renders it.

A: Ok – perhaps we can say that the instrument controller is responsible for finding the songs that use the instrument and returning it in a form that the view object can use.

B: Sounds good.

A: Ok, so what’s our first test

B: Well, we give it an instrument and it should find all the songs and return them.

A: That seems to be a lot for our first test. Perhaps we should split that into two tests and have one which returns a list of songs and one that asserts the songs are correct.

B: Cool, sounds good

A: Ok, so the first test name could be ShouldReturnListOfSongs and the second test could be ShouldReturnSongsWhichUseTheGivenInstrument. So, we want to assert that we get a list of songs. It is often useful to work bottom-up: work from the assertion up to the setup.

public void ShouldReturnListOfSongs()
{
	// Given

	// When

	// Then
	Assert.IsTrue(returnedList is List<Song>);
}
public void ShouldReturnSongsWhichUseTheGivenInstrument()
{
	Assert.Fail()
}

B: But where does returnedList come from

public void ShouldReturnListOfSongs()
{
	// Given

	// When
	InstrumentController controller = new InstrumentController();
	List<Song> returnedList = controller.FindSongs();

	// Then
	Assert.IsNotNull(returnedList);
}
public void ShouldReturnSongsWhichUseTheGivenInstrument()
{
	Assert.Fail()
}

A: Ok – your turn. Lets do the simplest thing to make that pass

public class InstrumentController
{
	public List<Song> FindSongs()
	{
		return new List<Song>();
	}
}

B: Cool. Ok, now I want to test that it finds the right songs from the database

A: Testing that we get the correct songs is good, but its not the responsibility of the controller to know that it is getting the songs from a database. What happens if you want to change your storage mechanism? Now you have to change everywhere that you just pulled information straight from it. Anyway, thats a how again. Lets get back to what it should do: return the songs which use the instrument.

public void ShouldReturnListOfSongs() { ... }
public void ShouldReturnSongsWhichUseTheGivenInstrument()
{
	// Given
	Song hereComeTheDrums = new SongBuilder().Build();

	// When
	InstrumentController controller = new InstrumentController();
	List<Song> returnedList = controller.FindSongs("drums");

	// Then
	List<Song> expectedSongs = Lists.Build(hereComesTheDrums);
	Assert.AreEqual(expectedSongs, returnedList);
}

A: Notice I have used a builder – this is so that our setup is not long, we know we have a valid Song object and if at anytime we need to change the way a song was constructed, we would only need to change the builder – not every test which created a Song. Now, we know that the controller needs to ask another object to do the finding, as it is not the controllers responsibility. An objet that usually encapsulates that work is called a Repository. As far as the controller is concerned, the Repository holds a bag full of Songs and it can ask it for songs that use instruments. It is the responsibility of the repository to actually find the songs. So, lets give the controller the repository when it is created.

public void ShouldReturnListOfSongs() { ... }
public void ShouldReturnSongsWhichUseTheGivenInstrument()
{
	// Given
	Song hereComeTheDrums = new SongBuilder().Build();
	ISongRepository songLibrary = new CannedSongRepository(hereComeTheDrums);

	// When
	InstrumentController controller = new InstrumentController(songLibrary);
	List<Song> returnedList = controller.FindSongs("drums");

	// Then
	List<Song> expectedSongs = Lists.Build(hereComeTheDrums);
	Assert.AreEqual(expectedSongs, returnedList);
}

A: Again, note that the controller takes in an interface and in the test we are using a Canned repository. A canned object is useful in testing as we can guarantee what it returns. Some people use mocking frameworks to stub the method call; the difference between a canned repository and a mock is that we can reuse the canned object without any effort in other tests, but we would need to recreate the mock every time. That leaves us with a failing test.

public class InstrumentController
{
	ISongRepository songLibrary;

	public InstrumentController(ISongRepository songs)
	{
		songLibrary = songs;
	}
	public List<Song> FindSongs(string instrument)
	{
		return songLibrary.Find(instrument);
	}
}

A: Right, now the only problem with the code is that I don’t really understand what the method Find does. I can’t look at it and instinctively know what it will do. It is not an intention revealing method name. Perhaps we can call it FindSongsWhichUse so that the code now reads

public class InstrumentController
{
	ISongRepository songLibrary;

	public InstrumentController(ISongRepository songs)
	{
		songLibrary = songs;
	}
	public List<Song> FindSongs(string instrument)
	{
		return songLibrary.FindSongsWhichUse(instrument);
	}
}

A: Now we have a choice – we can continue testing the controller or we can start testing the repository. If we test the repository, we can continue with a thin vertical slice, we can see the results on the page and get immediate feedback (this is my preferred method)

And so the development (and conversation) continued until we ended up with a nice design which was fully tested and only delivering what the business wanted.

• Test the what, not the how. Concentrate on the behaviour of your object, not how it will achieve that behaviour.
• Have minimal, simple setup. This will help drive out classes which have low dependancies, low coupling and single responsibility. Use builders to help you minimise the number of lines in your setup.
• Write your test bottom up – start with your assertion, then fill in the blanks
• Test one behaviour at a time (often referred to one assertion per test). If you hear the magic keyword And when describing the behaviour, you have two tests.
• It is useful to structure your test in the Given When Then format. This allows you to see the what is just there to form as setup and how much setup you need to do (in the Given), see the intention of the test (in the Then) and understand which method you should alter to make the test work (in the When).
• Naming is important. Give your test a good name – it will help with your documentation and it will also help you concentrate on what you are testing, not how it will be implemented. Also, names of your test variables should reveal the different examples of the values that could be used. Instead of declaring User user = new User(“mary jane”) try User maryJane = new User(“mary jane”) and see how that changes your understanding of the class.

In my next post I will share a conversation I had this week with my client, which shows how I introduce these characteristics to my test.

Take TDD for example – how can doing Test Driven Development/Design lead to good code? After all, you are only writing the same unit test before you write your code, instead of after. ‘How will that act magically transform my code base?’ The problem is that when you first hear about TDD, all you really hear is ‘Test First’. What you usually don’t hear is that when you actually test drive your application, you need to ensure that each test you write should be a good test, and it will look nothing like the tests you are used to writing. So, the first problem is that we don’t explain the what a good test should look like loudly enough.

Another problem is that you can’t expect a code base filled with statics and procedural code to magically transform by adding tests. The developers who are responsible for that code will continue to work on it, and they will find a way of writing unit tests which allows them to continue with their procedural code (although it will violate the rules of a good test). This will cause two bad side effects: tests will be hard to write, so developers will not get into the habit of test-first; and the code will still be as stinky as ever, so they won’t believe that TDD works. The other side of the coin is that the developers need to understand basic concepts and principles like single-responsibility, encapsulation and dependancy injection because without this understanding and mindset, it is really hard to write good tests, and the code base will never improve.

The other problem is that the developers don’t actually realise that they can’t just change how they write tests; they are actually changing how they think about code, how they write the code and how they design the code. And this can be scary, especially for the ‘technical architects’ who are used to spending a few weeks in front of a white board designing the application before writing a single line of code. It also takes a lot of discipline and you need to unlearn nearly all software development practices and instincts that you know. 

The simple phrase of “TDD will lead to better code” has bigger implications than just writing tests upfront. Those starting out on their XP journey need to understand the bigger ramifications before they can begin to embrace their new practices. Those in the know need to understand that others don’t realise that there are bigger ramifications and when they see the head scratching, try to explain why the phrase is so (hopefully this post will help).

TDD does lead to better code – test first does not.

public void ShouldCalculateVolume()
{
	Box box = new Box();
	box.Type = Cardboard;
	box.Width = 10;
	box.Height = 20;
	box.Depth = 40;
	Assert.AreEqual(8000, box.Volume)
}

However, there is a solution: builders. Builders help by allowing you to only setup the data relevant to the test, but still having a fully formed object. By chaining your methods, you also reduce the amount of lines required for setup. Another advantage of using builders is obvious when you start to refactor the object: instead of fixing all your tests because you have added a new mandatory field, you only have one point of failure.

public void ShouldCalculateVolume()
{
	Box box = new BoxBuilder().Width(10).Height(20).Depth(40).Build();
	Assert.AreEqual(8000, box.Volume)
}

public class BoxBuilder
{
	int width = 1;
	int height = 1;
	int depth = 1;
	Material type = Cardboard;

	public Box Build()
	{
		Box box = new Box();
		box.Type = Cardboard;
		box.Width = width;
		box.Height = height;
		box.Depth = depth;
		return box;
	}

	public BoxBuilder Width(width)
	{
		this.width = width;
		return this;
	}
	public BoxBuilder Height(height)
	{
		this.height = height;
		return this;
	}
	public BoxBuilder Depth(depth)
	{
		this.depth = depth;
		return this;
	}
}

Of course, my example is quite trivial and the only obvious benefit is that I put all the property definitions on one line. However, when you start adding other more complex objects (like perhaps those within your aggregate), then you have some powerful testing techniques under your fingers.

Unit testing is a method of testing that verifies the individual units of source code are working properly
http://en.wikipedia.org/wiki/Unit_testing

Integration testing…is the phase of software testing in which individual software modules are combined and tested as a group
http://en.wikipedia.org/wiki/Integration_testing

But what is the distinction between unit and integration tests? How granular do you make your unit tests? For instance, would you consider testing an aggregate object unit testing or integration testing? More importantly, what value do we get in declaring it.

When first learning how to write good tests, and learning about TDD and other wonderful testing practices, specifying what type of test you are writing helps define the boundaries of the test. Knowing this helps you know what objects to piece together to form the test for example to use a canned repository or use the real one. But once mastered, do you still need to explicitly call out the type. 

I understand that some people use these distinctions in their CI process – their CI build runs the unit tests first and then, only if they are successful, they run the integration (mainly database) tests, and then the “acceptance” tests. The main drivers for doing this are that, by their nature, unit tests are quite fast and so you fail fast; integration (and acceptance) tests are often too slow as they sometimes start up the whole framework, or talk to slow database connections.

If someone gave me these reasons I think I would run through the 5 Ys with them to make sure that the problem they were actually solving by separating out the integration tests was the correct problem. For instance:

Why do you run integration tests after your unit tests? Because they are slow and take a long time to run.
Why do they take a long time to run? Because Rails initializes the whole environment when testing.
Why do you need to initialize the environment? Umm…I guess I don’t need it for my tests…but Rails does it for me automatically.
Why don’t you remove this unneeded dependancy? Umm…..

That’s where I would probably stop with the questioning, because I would point them in the direction of George Malamidis’s work around for fast unit tests. My point is that there maybe a better solution than separating the tests.

So, what value do we really get by explicitly declaring what type a test should conform to?

Before I continue, I should describe my observations of acceptance testing. From what I’ve seen, acceptance tests are created as assurance that a story is complete. They are a layer above unit, integration and persistence tests. Their assertions are based around acceptance criteria, and verify the functionality for the story. And, from what I have seen (as with all other tests) they are not constantly maintained, once written forever forgotten, and quite long to run.

Somewhere down the road of the project, the build takes too long to run, or you spend too much time fixing broken acceptance tests or you have flaky acceptance tests, and your mind starts to filter out a red build, thinking the problem must be caused by the said flaky test. A common workaround to these problems is to stop writing as many acceptance tests.

I guess my biggest problem with acceptance testing (in this form) is that I can push down any assertion that is made in the acceptance tests onto integration, persistence or unit tests and have a higher level of confidence that the acceptance criteria has been met. In fact, when I finish developing my story, the integration/persistence/unit tests already cover all acceptance criteria.

Now, you might argue that acceptance tests make good reference material, as there is one place you can go do to find out what the story was meant to do at the time of sign-off. If this is true, why do I see developers constantly referring to the code or unit tests for this information, rather than the acceptance tests?

I don’t see the value of these story-based acceptance tests.

What I can see real value in is scenario-based testing. What I would like are a handful of scenario tests which describe the system as a whole. After all, the stories we develop have all been derived from some scenario which delivers business value. That way, as I develop a new story, I just extend the scenario tests to capture the essence of the story, but have all acceptance criteria still tested on the unit/integration tests.

Testing is a form of art; I don’t think we have mastered acceptance level testing. Perhaps scenario testing is the answer, but it requires constant improvement to them, maintaining them, refactoring were necessary; generally looking out for the well being of the tests: one thing I don’t think we are good at. Remember, refactoring your code base is just as important as refactoring your test code.

public void SuccessulUpdateOfCarDeatilsShouldReturnSuccessResponse()
{
CarController controller = new CarController()
controller.UpdateCarDetails(0, string.Empty, string.Empty, string.Empty)
Assert.AreEqual(200, controller.Response)
}

public class CarController{
...
public void UpdateCarDeatils(int carId, string carRegistration, string colour, string engineIdentificationNumber)
{
...
}
}

public void SuccessulUpdateOfCarDeatilsShouldReturnSuccessResponse()
{
CarController controller = new CarController()
controller.UpdateCarDetails(42, "car registration", "colour", "engineIdentificationNumber")
Assert.AreEqual(200, controller.Response)
}