Making your code easier to understand context/specification style unit tests

When we started our current project we did not use context/specification style testing, instead we used testcase-per-class with a four-phase test model (also known as arrange-act-assert). Although we followed story-test driven development (STDD) we were not explicitly Behavior-Driven Development BDD when we set out. Over time I began to see the path between STDD and BDD we shifted toward a BDD approach.

That is really background for what comes next. As part of this shift we started writing more context/specification style tests. We did not re-write our existing testcase-per-class fixtures (then and still now I would see the possibility of using multiple test organisational patterns within a project; some of our tests still seem better with testcase-per-class). Recently we have had new developers join the team. One interesting, if anecdotal, observation has been that those developers find it easier to use tests as a source of documentation for what the software is doing when they are in the context/specification style. This is a useful observation, because the rest of the team is able to supply much of the context for testcase-per-class fixtures by virtue of having worked on the codebase and so do not see the lack so easily.

To build a maintainable system you have to build one where the behavior can be understood. Tests offer this promise, but often we have found that tests failed us, because the tests were no easier to comprehend than the code under test. Context/specification style tests seem to be better on this account. Of course there is no silver bullet in software. You still have to put the effort into making your context/specification tests readable, but the form seems helpful toward achieving that goal.

I’ll try to post more on my experiences with BDD style approaches as they come out. I would also recommend that anyone interested in the topic look at the RSpec book from the Pragmatic Programmers which offers a great overview of the topic.




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.
This entry was posted in ATDD, BDD, Behavior Specification, STDD, TDD, xUnit. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Public Relations

    Finally! Someone who actually knows what they are talking about! Thanks for the info.

  • Public Relations

    thanks for the post! everyone could use better coding.

  • replacement window

    You got a really useful blog I have been here reading for about an hour. I am a newbee and your success is very much an inspiration for me. I would love some feedback on my sitewindow repair when you got time.

  • pool cleaner

    I can see that you are an expert at your field! I am launching a website soon, and your information will be very useful for me. Thanks for all your help and wishing you all the success in your business. Please come visit my site swimming pool equipment when you got time.

  • security companies

    I can see that you are an expert at your field! I am launching a website soon, and your information will be very useful for me. Thanks for all your help and wishing you all the success in your business. Please come visit my site pediatric neurology when you got time.

  • notaries

    This is just another reason why I like your website. I like your style of writing you tell your stories without out sending us to 5 other sites to complete the story. Please come visit my site notary public and give me any valuable feedbacks.

  • nursing jobs

    I am not really sure if best practices have emerged around things like that, but I am sure that your great job is clearly identifed. I was wondering if you offer any subscription to your RSS feeds as I would be very interested and can’t find any link to subscribe here. Please come visit my site nursing programs when you got time.

  • Scott

    Agreed on multiple test organizational patterns per project. c/s lends itself very well to business-value-driven design, and feels forced when you drop into “internals” or integration-style tests, where class-per-fixture begins to make more sense. I think it’s a shifting target, and ou have to constantly evaluate what you are getting out of the practice and how you can improve it.

  • Larry Battle

    When you release your code, what happens to the test functions?
    Does it go into your documentation and ship it or do you erease it because it’s a one time thing?

    I’m new to the unit testing.

  • Ian Cooper


    I have not looked at MSpec but noting that someone else has posted about MSpec and Boo might well take a look

  • Daniel Fernandes

    Agreed at 100%.

    Traditional TDD style tests are fine for driving design of a purely technical piece of code where you can probably guarantee that you’re always within the realm of unit testing and not diverging too much into integration testing.

    I think that the different forms of tests organization as advocated in BDD are very useful in that most often than not the organisation will closely match the various specifications a system/component is supposedly implementing.

    The only issue in BDD is to find the various core contexts that are worth setting up and then testing.
    But those contexts are really the state parts of the application can be in and if you can do that properly you will have highly tested AND maintainable code.


  • http://MurrayOn.NET/ Mike Murray

    Have you looked into Aaron Jensen’s MSpec here on CodeBetter? I’m trying it out on my own and like the direction MSpec is heading.

    For me, it makes the use of unit testing frameworks feel more natural as part of the behavior and specifications that frequently come down from the suits. It is a more high-level testing (yet more readable) that can be supplemented with regular class-driven unit testing when business requirements for a certain module are more vague.

  • David

    We’ve been through a similar thing at my work — starting out with testcase class per class, then switching to a more scenario-based testing style. We haven’t gone full context/spec or BDD, but I feel we’re at a pretty decent intermediate step at the moment.

    Here’s my write up of our approach: