Timeline for answer to Relation between BDD and TDD by Jörg W Mittag
Current License: CC BY-SA 3.0
Post Revisions
9 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 1, 2011 at 20:02 | comment | added | Jörg W Mittag | @Idsa: Note that there are many wrong descriptions of TDD, which don't include acceptance tests. Those -- unfortunately pretty popular and pretty widely taught -- wrong descriptions are one of the reasons why the BDD people thought it might be a good idea to rebrand TDD under a different name, to avoid the confusion. Nevertheless, and it cannot be repeated often enough, TDD and BDD are exactly the same thing. | |
| Oct 1, 2011 at 19:59 | comment | added | Jörg W Mittag | @Idsa: Yes, they are. I think Kent Beck calls this "Zoom In / Zoom Out", where you start with an acceptance test to define the scope of the feature, then zoom in to unit tests to flesh out the API and zoom back out again to the next acceptance test. Look at the testsuite for JUnit, for example, which, after all, was written by the creator of TDD. | |
| Oct 1, 2011 at 17:34 | comment | added | SiberianGuy | @pdr, I understand it is important to write acceptance tests even if your system is written by TDD. But are accpentance tests actually a part of TDD? I didn't find acceptance tests mention in any TDD definition | |
| Oct 1, 2011 at 17:31 | comment | added | Jörg W Mittag | @pdr: Yes, but if you actually read what e.g. Kent Beck has written about TDD, or, as he called it back then, Test-First Development, that's precisely what he always meant. The name change from Test-First to Test-Driven and then to Behavior-Driven was just to make it clear. | |
| Oct 1, 2011 at 16:25 | comment | added | pdr | Acceptance tests are an important part of TDD and BDD. But to say that BDD equals TDD is akin to saying TDD equals test-first. Unless you're allowing the tests to drive your code, you are not doing TDD (I used to know someone who was happy to write tests up front but argued that code should always be written as it would be if you weren't writing unit tests and that tests should be written accordingly). Likewise, unless you're allowing the behaviour to drive your tests, you are not doing BDD. | |
| Oct 1, 2011 at 15:03 | comment | added | Jörg W Mittag | @Idsa: In the same way that they are important for BDD, of course, since the two are the same thing! The acceptance tests drive the outer cycle of TDD, the one dealing with features and users, as opposed to the more detailed inner cycle which deals with APIs and protocols and such. I think Kent Beck calls this "Zoom In / Zoom Out". You can, for example, easily see this in the JUnit test suite, which contains probably at least as many acceptance tests as it contains unit tests. | |
| Oct 1, 2011 at 14:55 | comment | added | gbjbaanb | @Idsa: they're important in that your code should not pass the tests that you think they need to pass, but the ones that the code is supposed to do. I think too many people get confused by this, that most unit tests are low-level and thus avoid the difficult problem of testing what the system was written to do overall. | |
| Oct 1, 2011 at 14:46 | comment | added | SiberianGuy | In what way are acceptance tests an important part of TDD? | |
| Oct 1, 2011 at 14:40 | history | answered | Jörg W Mittag | CC BY-SA 3.0 |