Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
What is the relation of BDD and TDD?
From what I understood BDD adds two main things over TDD: tests naming (ensure/should) and acceptance tests. Should I follow TDD during development by BDD? If yes, should my TDD unit tests be named in the same ensure/should style?
BDD adds a cycle around the TDD cycle.
So you start with a behaviour and let that drive your tests, then let the tests drive the development. Ideally, BDD is driven by some kind of acceptance test, but that's not 100% necessary. As long as you have the expected behaviour defined, you're ok.
So, let's say that you're writing a Login Page.
Start with the happy path:
Given that I am on the login page
When I enter valid details
Then I should be logged into the site
And shown my default page
This Given-And-When-And-Then-And syntax is common in behaviour-driven development. One of the advantages of it is that it can be read (and, with training, written) by non-developers -- that is, your stakeholders can view the list of behaviours you have defined for successful completion of a task and see if it matches their expectations long before you release an incomplete product.
There is a scripting language, known as Gherkin, which looks a lot like the above and allows you to write test code behind the clauses in these behaviours. You should look for a Gherkin-based translator for your usual development framework. That's out of the scope of this answer.
Anyway, back to the behaviour. Your current application doesn't do this yet (if it does then why is someone requesting a change?), so you're failing this test, whether you're using a test runner or simply testing manually.
So now it's time to switch to the TDD cycle to provide that functionality.
Whether you're writing BDD or not, your tests should be named to a common syntax. One of the most common is the "should" syntax you described.
Write a test: ShouldAcceptValidDetails. Go through the Red-Green-Refactor cycle until you're happy with it. Do we now pass the behaviour test? If not, write another test: ShouldRedirectToUserDefaultPage. Red-Green-Refactor til you're happy. Wash, rinse, repeat until you fulfil the criteria set out in the behaviour.
And then we move on to the next behaviour.
Given that I am on the login page
When I enter an incorrect password
Then I should be returned to the login page
And shown the error "Incorrect Password"
Now you shouldn't have preempted this to pass your earlier behaviour. You should fail this test at this point. So drop back down to your TDD cycle.
And so on until you have your page.
Highly recommend The Rspec Book for learning more about BDD and TDD, even if you're not a Ruby developer.
My understanding of it:
So to address the TDD done right part of BDD. BDD started as a change in language of TDD to make the intention of the process clear. Dan North's introductory article on BDD explains why focusing on the word behaviour rather than test is useful - it helps confirm that you are not just building the software right, you are also building the right software. This was always part of a good TDD approach, but Dan codified it a bit into BDD.
What I think BDD makes a bit more explicit than TDD, or at least formalises and provides tool support for, is this two-cycle / double loop / zoom-in zoom-out / outside-in approach. You first describe the expected behaviour of the feature (the outside loop), then zoom-in to the inner loop to deal with the low-level specifications.
From http://www.metesreau.com/ncraft-workshop/
Gherkin in conjunction with tools like Cucumber and SpecFlow provide a way of writing those high-level feature specifications and then linking them in to code that executes the application code. I would argue that this is where BDD might 'feel' different from TDD, but it really still is doing the same thing, just with some added tool support and a DSL. Somewhat closer to 'traditional' TDD is using tools like rspec, nspec, spock. These feel a little more like the same process you'd do in 'traditional' TDD but with more behaviour-focused language.
In BDD in Action by John Ferguson Smart (highly recommended), he advocates for a double loop approach, starting with something like jBehave at the outer level executable specifications, then dropping into a tool like Spock for the low-level specifications.
BDD brings the concept of test-driven closer to the business stakeholders. Gherkin is designed to be business readable, and the idea of 'living documentation', i.e. automatically produced progress reports from your executable specifications is about giving feedback to the stakeholders.
Another part of BDD now, which is where it genuinely becomes something that incorporates TDD as part of a larger process, are the requirements elicitation bits and pieces. Ideas like Feature Injection, Impact Mapping, and Real Options are part of this side.
For the canonical answer on this, it might be best to go to Dan North again. If your team is all developers, then BDD = TDD. If your team involves a whole range of stakeholders, BDD is closer to XP, with TDD being one part of it.
What is the relation of BDD and TDD?
They are the same thing.
From what I understood BDD adds two main things over TDD: tests naming (ensure/should)
That's not really something BDD "adds". It's just a different convention that is meant to make it easier to teach and understand TDD.
The people who created BDD were all teaching TDD, and they noticed that the hardest thing to understand was that TDD has absolutely nothing to do with testing. Once students got over that hurdle, it went much easier for them. But, it's very hard to divorce yourself from thinking about testing, when the word "test" (or related terminology such as "assert") appears practically everywhere. So, they switched some words around.
But it's only the words! There is no actual difference between TDD and BDD.
and acceptance tests.
Acceptance tests are just as important a part of TDD as they are of BDD. Again: there is no difference between TDD and BDD: TDD done right is BDD, BDD is TDD done right.
It's the difference between writing the correct code (BDD) and writing the code correctly (TDD).
BDD is about specifying what the customer or user wants or needs in the form of one or more tests: The user has a problem they want the software to help them with, so how will we know that the software "behaves" the way it should and helps them solve the problem? We write a test (or a series of tests) that will verify when the proper behavior occurs. We then write code that makes the software pass the test(s), and so we know it behaves the way the user asked it to. Of course additional tests may define how the software should NOT behave, and those then also drive us to make sure the software complies.
TDD is about developers keeping code clean and adaptable by setting several rules:
This approach means that each test is specifying precisely what the next bit of code will do, giving you both comprehensive documentation and (once the tests pass) comprehensive code coverage. This level of coverage means that you can refactor your code (and your tests) at any time, so long as the tests all pass. This helps prevent technical debt and makes your code much easier to adapt as new requirements (in the form of tests) come in.
The major difference between BDD and TDD is that the behavioral tests in BDD are about what the customer is asking for, and these will probably be much larger than the single next little bit of code you're going to write. That is, they break TDD rule #2. Instead, a BDD behavioral test will probably fail for a little while we use TDD to drive the numerous bits of code that will make it pass. Once all the behavioral tests pass, we should be able to safely ship the code to the customer or user.
TDD on the other hand, helps developers ensure that the code is clean: with clear naming, limited duplication, short methods, etc., by giving them the ability to refactor it at any time. The advantage here is that when the next set of requirements come in, the code should be easily adapted to support them.
