Simple BDD/TDD

Todays theory is most tests and specs should be very short (2-3 lines), have at most a setup for context establishment, avoid the majority of test framework features as they should be used as an exception and not as a rule.  Note: I practice BDD nowadays and do not like using the term “test”, but these rules apply for BDD as well as TDD, and I imagine most of you practice TDD so I’ll be using primarily TDD terminology.

If you look at my first attempts at TDD they are very similar to my current BDD work with only changes in language. But the contexts, conditions and tests are similar. Most importantly they’re easy to read. They’re all very short, very descriptive, make limited use of arguments in the NUnit Attributes, and make very limited use of mocking.

Of course along the way I went down all sorts of terrible wrong paths, and with the help of Gerrard Meszaros plus some of my own experimentation I’m much happier with the time it takes to implement tests and the limited pain in refactoring my code.

Bad ideas I had along the way include:

  • Ran everything in TestFixtureSetup and TestFixtureTearDown or equivalent. Tests were all linked to one another
  • Mocked EVERYTHING and doing so with Record/Replay was double awful. Simple refactorings would break way more tests than they should. Test methods were 8-40 lines and unreadable at that.
  • Tried to sort everything by category with NUnit attributes. Took a fair amount of time for no payoff I can see (think about changing a category name when all you have is seemingly unrelated strings)
  • Tried to create “Story Classes” for testing. I know some people like this approach, I find them to be heavily coupled, fragile and noisy. Also this made finding individual examples of usage of individual classes difficult as now its “rules” were spread everywhere


Summary point avoid some of my mistakes, if you write short unit tests now..thats probably a good thing. If you are struggling with testability of your classes and you find your tests getting big, try and stop, sit down and make sure you are testing “one thing” and not really a big thing with many small pieces.

About Ryan Svihla

I consider myself a full stack polyglot, and I have been writing a lot of JS and Ruby as of late. Currently, I'm a solutions architect at DataStax
This entry was posted in BDD, TDD. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • I’d like to learn more about the BDD process and how to go about converting from a quasi-TDD practitioner to BDD. I’m interested not only in techniques and frameworks for writing tests but the changes to the actual process.

    I find it hard to locate good resources on the larger process as most articles focus on those style tests. Can you recommend anything that may have helped you gain deeper insights and understanding?

  • @Corey
    Forgot half the point of that last comment. You are going to find BDD is more about describing behavior of an object than about breaking off of TDD’s process model.

    Some people write up all of the _desired_ example behavior to start up with (SpecMaker has a RuleIs.Pending object just for that). Others follow typically TDD and just flow along never using Pending.

    None of this is I feel the important part of BDD, its focusing on describing an object (in C#’s case Class) in an “example” mentality rather than focus on testing.

  • bizzare Community Server ate my first comment.

    Book wise I’d suggest the RSpec book if you can read or have any concept of ruby. It describes the process in detail.

    There are a number of approaches and changes in ceremony among the BDD community. I trend towards minimalist, (the RSpec book for example goes a step further in parts than I’d recommend with Acceptance Driven Design)

  • I want to expand on your final point when you say “make sure you are testing ‘one thing’ and not really a big thing with many small pieces.” This also could say something about your code implementation and architecture, in addition to a possible smell in your testing code.

    Not only should your tests focus on testing “one thing,” but the subject under test should also focus on doing only “one thing,” as stated in the Single Responsibility Principle from SOLID. Your tests will be simple and focused if your code responsibilities are broken down sufficiently into focused, manageable chunks.

    Also, out of curiosity, and since you practice BDD, have you tried Aaron Jensen’s MSpec (Machine.Specifications)? It’s mostly a .NET port of RSpec from Ruby and seems promising. I have fiddled around with it on hobby projects, but nothing production-worthy yet. Here is a link:

    Rob Conery introduces it nicely here as well:

    Thanks for the post.

  • @Mike
    I’ve used MSpec and tried to teach it. I think the developers on MSpec are at least 14 times more experienced and intelligent than I am but ultimately I don’t like using the tool (and since its mostly opinion based and I’m in the minority I don’t see there being much point to going over why).

    I’m slowly making my own framework called “SpecMaker” which is closer to my primary goal for BDD, where I want to make BDD more accessible for new converts to the practice.

  • @Mike
    Also agree fully on your comment about smell. If you’ve done all you can to pare a test down to its minimal elements and its still too big or complicated, you’ve likely violated SRP.

  • Thanks Ryan. That makes a lot of sense and was put much simpler that I’d previously read. I’ll have to add the book you recommended to my ever growing list of “to read”.


  • Limiting complexity in BDD tests hints at the shift in mentality one should take when defining specifications. Context Specification uses this idea:

  • Limiting the complexity in tests suggests the shift in mentality needed when defining specifications. Context Specification adopts this idea:

  • @Micheal

    I think I’m advocating this now. While I appreciate your blog post, I’m lost how what I’m suggesting takes away from Context Specification.