BDD and TDD, what is the correct workflow?

Question

My understanding is such that:

BDD is the process of evaluating how software needs to behave, and then writing acceptance tests on which to base your code. You would write code using a TDD approach, by writing unit tests for methods and building your classes around the unit tests (code, test, refactor). When the code is written, you test it to see that is satisfies the original acceptance test.

Can anyone with experience of the entire comment on my interpretation and give a walk through of a simple application using these Agile principles? I see there is plenty of text on BDD and TDD in separate publications, but I am looking at how the two processes complement one another in real world development.

Answer 1

Try thinking of them as examples, rather than tests.

For the whole application, we come up with an example of how a user might use that application. The example is a specific instance of behaviour which illustrates that behaviour. So, for instance, we might say that a till application allows for refunds. A till operator who uses that till will be familiar with the scenario in which Fred brings back a microwave for a refund:

Given Fred bought a microwave for $100
When he brings the microwave back for a refund
Then he should get $100 refunded to his credit card.

Now it's easy to think of other scenarios too; for instance, the one where Fred got a discount and only gets $90 back, or the one where Fred had broken the microwave himself and we refuse his refund, etc.

When we actually start coding the till software, we break our code down into small pieces; classes, functions, modules, etc. We can describe the behaviour of a piece of code, and provide an example. So, for instance, we might say that a refund calculator should take discounts into account. This is only a small part of the refund scenario. We have a class, RefundCalculator, and a unit test with a method that says shouldTakeDiscountsIntoAccount.

We might put the steps for our example in comments, for instance:

// Given a microwave was sold at 10% discount for $100

...

// When we calculate the refund due

...

// Then the calculator should tell us it's $90.

...

Then we fill in the code to turn this into a unit test, and write the code that makes it pass.

Normally "BDD" refers to the scenario which describes the whole application, but the ideas actually started at a unit level, and the principles are the same. The only difference is that one is an example of a user using an application, and the other is an example of a class using another class (or function, or what have you). So BDD on the outside of an application is like ATDD (Acceptance-Test-Driven Development) and BDD for classes is like TDD. Hopefully this helps give you an idea of how the concepts hang together.

The only difference is that we got rid of the word "test", because we find it easier to ask people for an example than a test, and it helps keep people thinking about whether they understand the problem, rather than thinking about how to test a solution.

This answer on "top down" (or outside-in) vs. "bottom-up" may also help you.

Answer 2

Your summary is basically correct. The labels can be misleading: people who call what they do 'BDD' will write acceptance tests and unit tests, people who call what they do 'TDD' will write acceptance tests and unit tests. To me, the distinction between the two is much ado about nothing. You will read many people's experiences with different flavors of this basic process. Try the approaches that seem to make sense in your situation and always be ready to make adjustments based on what works and doesn't work for you - that's the essence of agile.

Answer 3

There are two approaches to BDD stories, imperative and declarative. A developer will likely find imperative stories easier to write especially when being used to script unit tests.

However when approaching this from Agile Test First/Test Driven Development approach a declarative approach results in BDD narratives that are cogent with the development stories. This is because the BDD narrative continues to reflect the domain language of the business rather than programming domain.

How do you capture requirements with declarative acceptance tests?