What is the difference between writing test cases for BDD and TDD?

  • I have been learning writing test cases for BDD (Behavior Driven Development) using specflow. If I write comprehensive tests with BDD, is it necessary to write TDD (Test Driven Development) test separately? Is it necessary to write test cases for both TDD and BDD separately, or are they effectively the same thing?

    It seems to me that both are same, the only difference being that BDD test cases can be understood by non developers and testers.

    That's one crucial difference, yes.

    BDD = Behavior Driven Development, for anyone else wondering. TDD = Test Driven Development, for completeness.

    Confusing BDD with TDD is like confusing Macroeconomics with Microeconomics. They are different. BDD = building an understanding of requirements using examples and optionally may be used to drive automated Macro tests. (agilenoir.biz/en/am-i-behavioral-or-not), TDD = writing micro tests to drive writing coding. The Agile Thoughts podcast covers these differences too: agilenoir.biz/en/agilethoughts/test-automation-pyramid-series

  • The difference between BDD and TDD is that BDD begins with a B and TDD begins with a T. But seriously, the gotcha with TDD is that too many developers focused on the "How" when writing their unit tests, so they ended up with very brittle tests that did nothing more than confirm that the system does what it does.

    BDD provides a new vocabulary and thus focus for writing a unit test. Basically it is a feature driven approach to TDD.

    Exactly. There is *no* difference between BDD and TDD. BDD is TDD done right. TDD done right is BDD. The problem is that doing TDD right is hard, or more precisely *learning* how to do TDD right is hard. The reason is that TDD has absolutely nothing whatsoever to do with testing, but it is hard to understand that important fact when all the terminology is about testing. So, BDD literally is just TDD with all the testing terminology replaced with behavioral examples terminology. It's like that "try not to think of a pink elephant" thing.

    I love the "Try not to think of a pink elephant" example because once you tell someone to do that, that's all they can think of LOL.

    Agreed. The trouble with TDD/BDD/xDD is that whichever one you come at first makes other approaches seem a little strange, the key point is not to worry about it too much and use whichever approach fits your circumstances best. A very common approach is to use BDD type approaches for the BA's to define your requirements (Given/When/Then in your stories) but the devs themselves don't use a BDD framework. They just convert the reqs. to TDD type approaches as they code and write unit/integration/acceptance tests in a standard xUnit type framework.

    there is no difference, one is a subset of another HOWEVER, there is a difference in that your acceptance criteria become living executables that drive your lower-level unit tests...so there's slightly an abstraction in the middle that you have to account for in code, the specifications (specs) that need to call your SUT code after your lower-level tests pass, the spec should pass. So the spec is what's introduced into BDD so you can't say there is no difference concretely. Sure you test drive the code using lower-level unit tests in both BUT there is also that added layer of specs on top

    @JörgWMittag "The reason is that TDD has absolutely nothing whatsoever to do with testing". How is this true considering that a fundamental part of the TDD process is writing and running tests? Seems to have rather a lot to do with testing.

    @DanB I'll give answering that a shot - I agree with Jörg's comment. Implicit in his comment is a heavy emphasis on the word 'development' - not development of the tests, but just development in the standard sense (of the application). As an approach to development, the details then become secondary (in this case, the detail that 'writing tests' are used as the approach to this type of development). In other words, Jörg's comments apply to the high-level view, where 'writing tests' is not part of the picture. Only at the level of detail do writing tests enter the picture.

    TDD and BDD are very different. The first is only meant to be used/done by software developers, while the second is meant to actively involve both developers and "customers" (end users, business experts, business analysts, or other project stakeholders who do not read/write programming code) in the creation of tests. And TDD is not only applicable to "unit" tests, but also to integration, functional, or end-to-end tests; as long as the tests are only read and written by developers, it's TDD; otherwise it's BDD.

    This answer is mostly right. The poster should edit out the bias that TDD produces “brittle tests.” Perhaps programmers make the tests brittle but the process doesn’t. The Agile Thoughts podcast covers TDD here http://agilenoir.biz/en/agilethoughts/why-developers-dont-tdd-a-radio-drama/

    I said that programmers make the tests brittle. I said there is no difference between the two just that BDD helps put the focus on behavior in their tests to help them write better tests.

License under CC-BY-SA with attribution

Content dated before 6/26/2020 9:53 AM