Over last 5 year, I have transition through different stages of mind set when it comes to unit testing or TDD in general. As an early adoptor I was curious to know to what extend we can take this concept. At this stage, my unit test looked more state testing i.e

[Test]

public void Should_Add_Two_Number()

{

    var number1 = 100;

    var number2 = 50;

    var sum = number1 + number2;

    sum.ShouldEqual(150);

}

As I moved further and realize power of maintainability and loosely coupled design, I started designing solution in terms of interfaces. With that my knowledge on TDD expanded towards interaction testing. Mocking frameworks like Rhino.Mock and Moq, TypeMock etc emerged during that timeframe to support such testing scenarios. And those test now started looking like this:

[Test]

public void Use_Is_Anything_when_args_are_not_important()

{

    const int intToReturn = 5;

    _stub = MockRepository.GenerateStub<ISampleInterface>();

    _stub.Stub(s => s.MethodThatReturnsInteger("foo")).Return(intToReturn);

    _stub.MethodThatReturnsInteger("foo").ShouldEqual(intToReturn);

}

Exploring further, I started utilizing more features provided by those mocking framework. Now you have way to not only  ensure method on stub/mock returns predictable value, but also make assertion that it was called with right argument. Taking this even further, when you have more services to interact with, these frameworks have option to assert sequence in which you call them. Example of first case may look like this:

[Test]

public void Use_GetArgumentsForCallsMadeOn_to_inspect_arguments()

{

    var interactor = new InteractingClass();

    interactor.CallTheInterfaceTwice(_mock);

    IList<object[]> argsPerCall = _mock.GetArgumentsForCallsMadeOn(m => m.MethodThatReturnsInteger(null));

    argsPerCall[0][0].ShouldEqual("foo");

    argsPerCall[1][0].ShouldEqual("bar");

}

Picture looked quite rosy here until I passed over excitement phase and entered phase of maintaining such software. Refactoring such code became painful job now. That is precisely because I have my logic duplicated at two places, one in production code and one in test. Every single change that I make in production code has to be reflected into test interaction as well. This is direct violation of fundamental principle of OOP.  This indeed is one of the code-smell whose root is buried in wrong choice of underlying software design.

Now let’s step back and analyze what has gone wrong over this journey. Moving from state base test into interaction base test has its value under certain situation. However as we move towards “loosely coupled” and “highly cohesive” software architecture design, underlying elements are all services that works together to achieve given use case. Unit testing at those service level yields sweet fruit in terms of coverage and confidence in being able to refactor codebase at any give time. However there is little value in testing interaction between these services and their sequencing with much of mocks.

Big question that remains here then would be “How do I ensure those end to end scenarios are covered under test?”. Well, the answer is hidden inside question itself. Coverage on “End to end scenarios” needs “End to End” testing. That’s exact where  Integration test has real value to demonstrate. For the case of web page which let user fill in form and take some action, typically such integration test will include testing all but the actual UI layer. In language of CommandProcessor from MvcContrib, it is called PageTester.  Last but not least is UI Tests which ensures application level configuration and environment is set up correctly.

Till next time. Code smartly.

Interested in Agile? Download a Copy of our Whitepaper ‘The Agile Difference’