I was listening to another good Hanselminuets podcast - Understanding BDD and NSpec with Matt Florence and Amir Rajan. As always it was a good an informative show. Towards the end of the show one of the interviewees (I think it was Amir) explained why BDD is much better than TDD…
For those of you who does not know what I’m talking about – TDD is Test Driven Development (or design) and BDD is Behavior Driven Development. TDD is more “low level” talking about unit tests and integration tests and how to write code that test code while BDD is about specifications and behaviors.
In TDD we talk about Arrange Act Assert while in BDD we have Given When Then
Each methodology has its own frameworks that help write and run tests (or specifications) that make sure our code does what it meant to do.
Am I the only one that see a resemblance?
You might argue that one is better than the other till you blue in the face it does not change the fact that they are two sides of the same coin.
There are differences – BDD is more “high level” dealing with specifications and was intended to be used by domain experts as well as developers – although I’m yet to find the product manager that would write specifications. On the other side TDD is developer oriented and intended to be used by people who write and read code daily.
But regardless of these differences I don’t really see a reason why you should choose one over the other. I confess I use TDD and unit/integration tests in most of my projects but I do have several projects where I use both. I like the fact that I can write unit tests as well as specifications – because I need to test both. I also find myself using unit testing framework (i.e. NUnit) to write more “BDD’ish” kind of tests.
And so I don’t really understand why one is better than the other. Mainly because I prefer to use both – when possible.
And if you never tried BDD (or TDD) before I suggest you do and see for yourself.
Happy Coding…
Hi Dror, maybe I can help clarify some things :-).
I completely agree with you, I really don't like the delineation between TDD and BDD either. I think this delineation has come to existence to show that writing your tests first isn't enough...and instead of elaborating on that and clarifying TDD, we as a community have decided to create yet another three letter acronym...BDD.
At the end of the day all I want is a valuable test, ie a test that communicates intent, tells a good story, and protects the next developer that needs to maintain the system.
Here is how I ensure a valuable test:
- I don't delineate between integration and unit test anymore.
Why write a "unit" test if it doesn't tell a good story for the next developer?
Is it worth mocking out all external dependencies to a point where a given component looses its meaning?
We tend to do that when we label a test as a "unit" test.
- I start with a "coarse grained" test, which is a test that gives enough context to tell a good story. It may use many components together, which is perfectly okay.
- When I see myself doing the same setup over and over again for a "coarse grained" test, at this point I decide whether it's okay to create a "finer grained" test for one of the internal components, sometimes it's the right choice, sometimes I keep things at the "coarse grained" level because it communicates intent better. I keep things relentlessly DRY throughout this process...moving common setup to shared methods.
- I try not to test the "how", I only test the "what". I try to avoid testing "structure", I imply structure while directly testing the "what".
Here are some examples of some NOT so great "BDD style" tests:
"when creating a blog post, it gets inserted into the database" (testing the how)
"given a car, it has 4 wheels" (testing structure)
"a blog post has a title and a body" (testing structure)
Here are the same tests that are more valuable:
"when creating a blog post, it is visible on the home page" (no mention of a database, a more coarse grained test because it incorporates retrieval of a blog post)
"a car is driveable if it has 4 wheels" (implies structure through some behavior we can assert)
"a blog is valid if it has a title" (implies structure through some validation behavior)
"retrieving a blog post shows the title and body" (still trying to avoid testing structure directly)
"listing blogs shows a summary of the blog, which is the first 1000 characters of the body" (testing listing of blog posts, introducing summary and body)
Here are some BDD tests I've written using NSpec they may help clarify these points:
- A kata about a piece trying to move around a map that has obstacles: https://gist.github.com/1115867
- A kata describing how one poker hand beats another: https://gist.github.com/1412830
- Reference implementation for a dynamic ASP.NET MVC Application (Blog Engine): http://bit.ly/uJ0Sqm
- More Complex reference implementation for a dynamic ASP.NET MVC Application (Video Game Trading Website): http://bit.ly/rSN1so
- Test suite for a dynamic ORM: http://bit.ly/rVjaLV
Hope that helps!