Eamonn Faherty

This is the last blog post I plan to make about the terminology around TDD. There will be real life examples from now on.
I have previously discussed the terms collaborators, subject under test (SUT) and test doubles. Here, I am going to describe the three types of test doubles you can use.

The Real Thing
If you have a simple collaborator which only really stores and retrieves values, like a model, then is it worth replacing it for testing purposes? I personally think as long as this collaborator is unit tested then it is okay. Once there is some logic in the collaborator, some mutator methods, then I think you must refactor your unit tests and use a proper test double.

Stubs
Stubs are replacements for collaborators with pre-programmed responses for requests and fields that store inputs:

public function get username():String {
    return "eamonn";
}
public function set username(username:String):void {
    _usernameSetDuringTest = username;
}

The first method does two important things. It makes your code deterministic. Your collaborator will always return “eamonn” as a username. It also means that the only complicated thing is your subject under test. Both of these things are very important for unit testing code.
The second method stores the input sent to the object. The field _usernameSetDuringTest can be queried later to find out if the test should pass or fail.

Mocks
Mocks are objects setup to expect interactions. When you use a mock you define which methods on it should be called and which parameters it expects. You run your test code and then you verify that the mock has been interacted with in the way you thought it should have been.

My Thoughts
From my experience I have found mocks to be very frustrating. Unit tests that use mocks are more tightly coupled to the production code and this makes refactoring harder.
If I rename the method in the example above I have the following changes:
If using a mock, I would change the name of the method in the real collaborator, the test double and in the unit test as it would be listed as a method that should be called.
or
If using a stub, I would change the name of the method in the real collaborator and in the test double
If I am using FDT and these two classes implement the same interface I can use the refactor -> rename method tool within FDT. This handles the rename when using a stub. It cannot currently handle the change if I had used a mock.
This might seem like a lazy reason to use a stub over a mock but you will have to consider when you will be making this change. It will probably be a very high priority bug fix needed a year after you wrote the code and you will probably want to get it resolved ASAP. There are many other reasons to use stubs over mocks but I think you should make that decision with your team or for yourself. Here is a really good article on the differences between mocks and stubs. It also spiders onto other good articles on other testing approaches. It is definitely worth checking out if you have the time.

I have been posting about design patterns recently and I am realizing that it would be useful to post about Test Driven Development too.

As a gentle introduction I am going to go through some of the vocabulary.

Test Driven Development is the process; Red, Green, Refactor. That is the easy way to remember it. Below is your workflow:

1) Write a unit test. A unit test is a method that tests another method. The test calls the method that you are testing and verifies that the response is as expected. Your unit test should always use the same inputs and should always expect the same response. The class containing the method you are testing is called your subject under test (SUT).

public function testAddingTwoNumbers():void {
    var result:int = sut.add(2,3);
    assertEquals(5, result);
}

2) Run your unit test. It should fail. This feels kind of silly but this is the best (easiest) way to check that the test is being run. This is the RED stage.

3) Write some source code that makes the test pass. This should simple literal values. Run your test and it should pass. This is the GREEN stage. This also feels silly but it proves your test passes before you add the complex logic in there.

public function add(valueOne:int, valueTwo:int):int {
    return 5;
}

4) This is now where you refactor. You take steps to make your design better. It is up to you how far to take the refactoring. In this example I would change the method to the following:

public function add(valueOne:int, valueTwo:int):int {
    return valueOne + valueTwo;
}

The example above was trivial. The add method does not use any other objects. If it did the correct name for those objects would be a collaborator. When you are TDD’ing you should replace collaborators with simple objects that return simple values. These are referred to as test doubles, after the term stunt double. You can use patterns such as the IOC pattern and Factory patterns to make it easier to replace collaborators with test doubles. That is coming in post 2!