Click here to Skip to main content
13,195,026 members (86,617 online)
Click here to Skip to main content
Add your own
alternative version

Tagged as


5 bookmarked
Posted 1 Feb 2010

The advantage of using BDD over TDD

, 1 Feb 2010
Rate this:
Please Sign up or sign in to vote.
After reading the latest post from @jeremydmiller, I felt the urge to write a small article about the BDD part since there might be missing a vital part here about BDD...


After reading the latest post from @jeremydmiller, I felt the urge to write a small article about the BDD part since there might be missing a vital part here about BDD...

What is true BDD?

For a general introduction on BDD, I would like to refer you to Wikipedia. There are also a lot of articles on this blog on specific issues as well.

Just to get an idea, I'll show you an excerpt of a spec (taken from here):

Define a browser
 using Be.Corebvba.Aubergine.Examples.Website.Contexts.BrowserContext
  from Be.Corebvba.Aubergine.Examples.DLL

Story Make sure my website gets enough visibility
    Is about a browser
    As a website owner
    I want to make sure that I get enough visibility
    So that I can get enough traffic

    Scenario Search results for 'keywords' on searchengine 
	should contain ''
        Given the current url is 'search url'
        When searching for 'keywords'
        Then the result should contain ''
        | searchengine | search url                     | keywords         |
        | google       | | BDD .Net         |
        | bing         |  | core bvba tom    |
        | bing         |  | Quantum physics  |
        | faulty link  | http://www.googleaaa           | core bvba tom    |

    Scenario Search results on google for keywords should contain ''
        Given the current url is ''
        When searching for the following keywords
            | keywords  |
            | Aubergine |
            | BDD       |
        Then the result should contain '' and the following markup elements
            | type | inner     |
            | em   | BDD       |
            | em   | Aubergine |

Each time I compile my application, these tests get executed, and I get a report about which tests fail and which tests succeed, so your customer knows which functionalities are working.

In a true bdd engine, specs are written using an intermediate language (a.k.a. ubiquitous language).
The biggest advantage of this extra layer is that it makes your specs completely independent from your design/infrastructure implementation.

This also implies that I personally do not consider engines that require writing your specs in code (like @aaronjensen's mspec for example) as true BDD engines. (Please do note that this is my personal opinion.)

Why Is That An Advantage ?

The first advantage is that this domain language is usable/understandable by domain experts as well. All you have to do is send them a link to the latest build bdd HTML report, and they know what to expect from your app...
Given that you explain the available grammar for a context to a domain expert, he/she should even be able to write their own scenarios. (Hence, my bdd engine has a commandline option to get the available grammar from a context DLL, so in theory you could send the compiled DLL to the domain expert and let him/her write the specs.)

The second one is a bit less obvious, and is why one requires the ubiquitous language in a true BDD engine: since behaviour almost never changes, you can simply replace complete parts of an application without having to rewrite your specs. Instead of fixing tests, you only need to fix your contexts.

You never have to rewrite your specs, since the behaviour does not change, it's only the implementation that does.

Fixing context implementations is usually less work compared to rewriting tests since a test usually contains some/a lot of dependencies in comparison to a single sentence of context grammar (which typically handles only a single dependency).

As an example, I am giving this analogy: if behavioural tests would be an app written using an ioc container and dependency injection principles, then unit tests would be an app written without them.

If you apply bdd-like practices to tdd (also known as Arrange/Act/Assert), you are missing out on a large part of BDD IMHO; it is like writing your apps using dependency injection, but without using a container: it works and it makes your code better, but you could make your life a lot easier if you would use a container.


Whether you *do* start using BDD is completely up to you. As you might know, there is no silver bullet, but it might be a tool that helps a little.

In my personal experiences opinion BDD is currently the way to go; but I might be a bit opinionated, since I have been dogfooding my own BDD engine for a few months now...

And for those of you why think I am suffering from the "Not-invented-here"-syndrome, you are probably right - although I have written an Aubergine manifest to explain why we needed another bdd engine- .

Happy development !!


This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)


About the Author

Tom Janssens
Founder Virtual Sales Lab
Belgium Belgium

You may also be interested in...


Comments and Discussions

GeneralNice post Pin
alex turner1-Feb-10 1:38
memberalex turner1-Feb-10 1:38 
AnswerRe: Nice post Pin
Tom Janssens1-Feb-10 1:51
memberTom Janssens1-Feb-10 1:51 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

Permalink | Advertise | Privacy | Terms of Use | Mobile
Web04 | 2.8.171018.2 | Last Updated 1 Feb 2010
Article Copyright 2010 by Tom Janssens
Everything else Copyright © CodeProject, 1999-2017
Layout: fixed | fluid