With Services the focus is on behavior

Posted by Ian Cooper on February 21, 2009

This post is really just tying together some ideas. A year ago I posted on my preference for classicist TDD. However, when it comes to services you are dealing only with behavior not state so using classicist approaches becomes trickier. One way out of this issue is to test the results of the service on the stateful objects (entities, repositories) that the service interacts with. Having experimented with that style the outcome is usually unsatisfactory because the service’s tests frequently mirror the tests against the stateful objects themselves. That leads to un-needed code (or worse duplicated code) in the tests, and multiple tests failing when you get something wrong.

So I think this is one of those cases where it is clear that the way to test the System Under Test (SUT – the service you are testing in this case) is by its interaction with its depended upon components (DoC).

I also think that this approach helps prevent the obesity issues with Fat Controllers and Flabby Services because it discourages you from adding much additional behavior to your service beyond command and control logic, because it is then hard to test that outcomes of that logic.

So in the context of services I would vote for looking at ‘mocking’ as an approach.

For controllers, we have found auto-mocking containers to be a powerful way to get our code under test.

About Ian Cooper

Ian Cooper has over 18 years of experience delivering Microsoft platform solutions in government, healthcare, and finance. During that time he has worked for the DTi, Reuters, Sungard, Misys and Beazley delivering everything from bespoke enterpise solutions to 'shrink-wrapped' products to thousands of customers. Ian is a passionate exponent of the benefits of OO and Agile. He is test-infected and contagious. When he is not writing C# code he is also the and founder of the London .NET user group. http://www.dnug.org.uk
This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • http://colinjack.blogspot.com Colin Jack

    Wondering how you test the interactions with entities using mocking, are you mocking the entities themselves?

  • Ian Cooper

    @Colin

    Our aggegate roots have virtual public methods, so this is not such an issue for us. .Net developers seem over-concerned about the implications of making methods virtual,. unlike say Java where it is the default. For classes that form a facade to some underlying complexity, as a root does, making methods virtual can really improve testability.

  • Ian Cooper

    @Colin BTW in the past we have had conversations around Rebecca Wirf-Brocks notion of object neighbourhoods as being the sweet spot for using concrete dependencies in tests as opposed to mocking them out. Right now I think that aggregate roots fulfill this within DDD. Within the aggregate, or when testing the aggregate root itself, I would tend to think that for stateful depended upon components you should use the concrete type, but when dealing with other aggregate roots or from a service level then mocks may be test doubles may be more appropriate to hide the internal implementation details of what lives ‘behind the fence’ from the test.