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!)
| TDD | BDD |
|---|---|
| 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. |
Liz Keogh, lunivore 
Liz,
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
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!
jon
Fixture: context .. ?
Hi Liz.
I love this list. One change I would make:
passing -> behaving
failing -> misbehaving, or not behaving (or behaving strangely?!)
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.)
Liz,
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.
Totally awesome!!!
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??
thanks
Ram
Ram, get hold of the RSpec Book and the Cucumber Book. They have lots of very clear tutorials in them.
Pingback: Le BDD mis en oeuvre avec JBehave | Blog Arolla
Pingback: Labcamp – BDD with Jasmine – Blog by Jelizaveta Potapova
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.
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!
Pingback: Behavior Driven Development (BDD)