How BDD complements TDD

2018-06-16 03:05:43

Since I heard about BDD(Behaviour driven development) I have been wondering if it complements TDD? Is it actually useful in web development? As a busy .net web developer is it worth spending time on BDD as well as TDD? When I have gone through it I found it quite interesting but I am confused about how it is useful for us!

I have come across this quote, but what does it actually mean?

Although these tools are often developed specifically for use in BDD projects, they can be seen as specialized forms of the tooling that supports test-driven development. The tools serve to add automation to the ubiquitous language that is a central theme of BDD.

First, some definitions;

TDD is Test Driven Development, as the name suggests the tests we produce drive the flow of our development. Its commonly described in conjunction with a Red-Green-Refactor cycle. So in practice we write a unit test and it fails, giving us a Red state, then we fix the code of our application until we pass the test, giving us a Green state, and finally we refactor our application code and our testing code so that we have good design. Good TDD works by focusing each test on a single method in the class that we want to test and injecting mocked dependencies so we are testing the smallest possible amount of code, this leads to test suites where a single bug, results in a single failure.

BDD is Behaviour driven development, where the behaviour is the driving factor of our design process. When you follow a BDD process you engage with people to work out how your application should function, what its features are and capture some examples of the scenarios that it should operate in. In fact we can also consider BDD a cycle where we gather a new feature that the application should have, verify that the application works for all the scenarios, possibly refactor our tests so they make most sense and repeat all over again. BDD testing often requires many classes collaborating to produce a single business feature, so even if a bug triggers just a single failure you still have a large amount of code to track down the responsible code.

At this point you can see that BDD works at a higher level than TDD, in fact I have seen the BDD outer cycle succesfully used to drive a TDD inner cycle in more than one organisation, ie

Define new business feature
 ---> Add scenario and test: BDD Red
|     -> Add Unit test: TDD Red
|    |   Add application code: TDD Green
|     -- Refactor code: TDD refactor
|    Scenario passes: BDD green
 --- Refactor feature and scenarios: BDD refactor
Feature complete

Gojko Adzic describes this far better in his presentation TDD:Breaking the mould

How it is actually useful in web development? BDD is very useful in terms of a process used to gather requirements and through BDD tools, to automatically confirm that your codebase has all the features that the business requires. I find that BDD works best with integration style testing with many classes collaborating, instead of unit testing focusing on a single method.

You would use BDD to build your application logic, and you can use it to test most of your website. I would personally shy away from testing the UI and instead work in the code-behind, using language such as "When the User searches for BDD", however some people using Selenium and write tests that talk about clicks and testboxes "When the user enters BDD in the search textbox And clicks the search button".

Is it worth spending time on BDD as well as TDD as a busy web developer in .net?

Hopefully by now you should be able to answer that question for yourself. You need to decide how much benefit you are going to get from introducing BDD into your process. Your benefits will vary depending on factors such as team size and tools that you choose.

I note that you are looking at the plain text specification form of BDD tooling by tagging your question with nBehave. This enables you to have a BA team working on the plain text scenarios and submitting them back (although don't leave it all to them, you need some technical input to keep the scenarios consistent). Other forms of tooling such as mSpec work the other way, using C# to describe the scenarios and generating the plain text as a result of the build process. Personally I use SpecFlow which has all benefits of nBehave but its tests can be run via the nUnit runner, resharper and your build server. However you might want to keep your integration tests separate from your unit tests and report different levels of coverage for example.

And finally

This means that the BDD tools work in similar ways to our existing TDD tools, and know how to generate or understand the BDD grammar of Given When Then. For more on this I'd recommend reading https://github.com/cucumber/cucumber/wiki/Gherkin.

If you want to know more about BDD as a process then Liz Keogh has a lot of really good material, start here http://lizkeogh.com/behaviour-driven-development/

(And whoops this is a lot longer than I thought it would be when I started)

The key difference between TDD and BDD is the scope. TDD is a development practice while BDD is a team methodology. In TDD, the developers write the tests while in BDD the automated specifications are created by users or testers (with developers wiring them to the code under test.) For small, co-located, developer-centric teams, TDD and BDD are effectively the same.

There is comprehensive answer on your both questions here.

Some code samples of TDD and BDD you can find here

BDD补充了TDD

The idea with Cucumber (and BDD in general) is that stakeholders assist in writing scenarios - or executable specifications. This solves the where do we start problem with TDD.

http://dannorth.net/introducing-bdd

链接地址: http://www.djcxy.com/p/45696.html

上一篇: Unminify / Decompress JavaScript的工具

下一篇: BDD如何补充TDD