Translating TDD to BDD

Prompted by the recent twitter storm, prompted by Uncle Bob, Justin Etheridge and Cashto, here’s some sample language that I use when I’m coaching or thinking about BDD, instead of TDD. I’ve found this language really helps people adopt TDD (for my flavour of it!)

More on this soon.

test example
class under test class we’re describing
method under test valuable behaviour
what to test why is this class valuable?
how to test how do I want to use this class?
interface role
mock collaborator playing <this> role
design responsibility
passing working, providing value
failing should it do what I’ve described?
verify that ensure that
assert that ensure that
returns true / false tells me that…
returns <object> gives me…
implements <interface> provides <the benefit of the role>
pinning the code down so it won’t break making the code easy to
use, understand and change.
100% coverage Please, come change my code. I believe I’ve given you enough information to do this safely.
This entry was posted in bdd. Bookmark the permalink.

14 Responses to Translating TDD to BDD

  1. Ben Rady says:


    Given this terminology, can you reword these sentences to eliminate the TDD terminology, but in such a way that someone who doesn’t know what BDD is can understand it?

    “Writing the tests first ensures that the code we write to make them pass is actually testable. Otherwise, we may wind up with classes and methods that, although fairly well designed, are not easily tested”

    P.S. Thanks for the suggestions via twitter

  2. jon says:

    Great post! As a newcomer to BDD, seeing the terminology side-by-side really helps me understand the difference in mindset. Very useful — I’ll be passing it on!


  3. Matt Hinze says:

    Fixture: context .. ?

  4. Dan North says:

    Hi Liz.

    I love this list. One change I would make:

    passing -> behaving
    failing -> misbehaving, or not behaving (or behaving strangely?!)

  5. liz says:

    Here you go, Ben:

    Writing examples of how to use the code, before we write the code that makes those examples work, ensures that the code we write is easy to use and understand. Otherwise, we may wind up with code that, although adhering to SOLID principles, has been written to be easy to write rather than easy to use or maintain.

    (Of course, if you’re doing true outside-in then you already have one example of how to use a piece of code, from its consuming class. I reworded this from ‘well-designed’ to ‘adhering to SOLID principles’, since they’re necessary for good design but IMHO not sufficient.)

  6. Ben Rady says:


    That’s beautiful. I especially like how you phrased your points about use and maintenance. Takes the focus off “testing” and puts it on something that’s more directly tied to value.

  7. szczepiq says:

    Totally awesome!!!

  8. Ram says:

    this post is Awesome i am doing my acadamic project on TDD and BDD . this post helped me a lot to understand TDD and BDD together.

    can you please provede me any links for tutorials of BDD in RUBY using CUCUMBER??



  9. liz says:

    Ram, get hold of the RSpec Book and the Cucumber Book. They have lots of very clear tutorials in them.

  10. Pingback: Le BDD mis en oeuvre avec JBehave | Blog Arolla

  11. Pingback: Labcamp – BDD with Jasmine – Blog by Jelizaveta Potapova

  12. Ko says:

    Hi, I am a newcomer for this methodology and the above clarification is good. Can you please provede me URL links for tutorials of BDD & TDD.

    • Liz says:

      Hi Ko, I haven’t written any myself. All I would be doing is typing into Google what you can type yourself. Try “TDD Kata” too. Good luck!

  13. Pingback: Behavior Driven Development (BDD)

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s