BDD and TDD, what is the correct workflow?
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.
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.
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.
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?
Include batman test_case
Mocking objects instantiated inside a class to be tested
How can I do TDD with Joomla 3.2?
Does TDD in Puppet make sense, if positive how to implement it
Why we should start with a failing test in TDD?
TDD is applicable all the time? [closed]
Avoiding code duplication when defining Gherkin Given and When statements
Guard : phpunit is not installed on your machine
How to write User Stories for technical implementation details?
Test Driven Development process
The following setups were not matched - converting JustMock to Moq
Fitnesse ScenarioLibrary is not being included in the tests
How to TDD a 2-steps process which requires input from a remote party?
What are the guiding principles when practicing TDD? [closed]
TDD: refactoring and global regressions
Cucumber capybara fill_in failing