Converting tests to specs is a bad idea

When I first started experimenting with BDD, all the talk about the shift in language led me to believe that to “do BDD” all I needed to do was to change my “Asserts” to some “Shoulds”. At the root, it looked like all I was really doing was changing the order of my “expected” and “actual”.

In my admittedly short experiences so far, I’ve found that BDD is much more than naming conventions, language, and some macros. For me, unit testing was about verifying implementations while specifications were about specifying behavior. Although I’m not supposed to test implementations with unit testing, conventions led me down this path. It’s easy to fall into the trap of testing implementations, given constraints we put on ourselves when writing unit tests.

When I wrote the implementation test-first, I first got a requirement or specification from the business. It sounded something like “We want to be able to transfer money between two accounts”.

Before I started writing my tests, I had to figure a few things out. Our naming conventions forced us into a path that made us choose where the behavior was supposed to reside, as we named our test fixtures “<ClassUnderTest>Tests”. In the example above, we’re testing the “AccountService” class. Additionally, our individual tests were named “<MethodName>_<StateUnderTest>_<ExpectedBehavior>”. We took these naming conventions because it organized the class behavior quite nicely according to members.

Converting to BDD syntax

I wanted to try BDD, so the quickest way I saw to do it was to change the names of our tests and switch around our assertions:

Now that I see the word “Should” everywhere, that means I’m doing BDD, right?

Just leave it alone

BDD is much more than naming conventions and the word “should”, it’s more about starting with a context, then defining behavior outside of any hint of an implementation. When creating my Transfer test initially, before I could start writing ANY code, because of our naming conventions I had to decide two things:

What class does the behavior belong

What method name should be assigned to the behavior

But when writing true BDD-style specs, I don’t care about the underlying class or method names. All I care about is the context and specifications, and that’s it! If I was writing the Transfer behavior BDD-first, I might end up with this:

The key difference here is nowhere in the fixture nor the test method name will you find any mention of types, member names, or anything that hints at an implementation. I’m driven purely by behavior, which led me to a completely different design than my test-first design. In the future, if I decide to change the underlying implementation, I don’t need to do anything with my BDD specs. When I’ve decoupled my implementation of behavior completely from the specification of behavior, I can make much more dramatic design changes, as I won’t be bound by my tests.

I’ve also found I don’t modify specifications nearly as much as I used to modify tests. If behavior is changed, I delete the original spec and add a new one.

So don’t trick yourself into thinking that you need to modify your tests to become BDD-like. Just leave those tests alone, they’re doing exactly what they’re designed to do. A single context is likely split across many, many test fixtures, so it’s just not an exercise worth undertaking. Start your BDD specs fresh, unencumbered from existing test code, and the transition will be much, much easier.

About Jimmy Bogard

I'm a technical architect with Headspring in Austin, TX. I focus on DDD, distributed systems, and any other acronym-centric design/architecture/methodology. I created AutoMapper and am a co-author of the ASP.NET MVC in Action books.

Great post, really interested to hear more about how you make BDD/TDD work well together in your codebase.

http://sirenian.livejournal.com Elizabeth Keogh

“BDD is much more than naming conventions and the word “should”, it’s more about starting with a context, then defining behavior outside of any hint of an implementation.”

BDD is mostly about talking to the business in a language that they understand, then carrying that language into the code. Naming things “should” makes that easier, but please don’t forget to have the conversations! Read Eric Evans’ “Domain Driven Design”, which covers the ubiquitous language bit of BDD.

About Me

I'm a technical architect with Headspring in Austin, TX. I focus on DDD, distributed systems, and any other acronym-centric design/architecture/methodology. I created AutoMapper and am a co-author of the ASP.NET MVC in Action books.