Menu
The more I read about BDD and how it is supposed to be improved TDD the more confusing it all seems to me. I've found quotes from expert that say it's about design, but also from other experts that say it's about analysis.
The way I currently see it is this:
1) analysis: BDD
from wikipedia
The result of object-oriented analysis is a description of what the system is functionally required to do, in the form of a conceptual model.
So after BDD we have the requirements (stories and the scenarios). But I'm not sure about the conceptual model part.
2) design: eg with tools like resonsibility driven design using CRC cards
3) code: coding the design, optionally use testing (like what they say about TDD done wrong, which I also find useful)
Am I wrong in how I see this? I'm having trouble seeing the forest through the trees at the moment.
592
BDD allows developers to do the above by : Allowing the requirements to be defined in a standard approach using simple English. Providing several ways to illustrate real-world scenarios for understanding requirements.
Behavior-driven development revolves around conducting behavior-specific tests, or functional specifications that outline executable scenarios for the application. This includes: Applying the 5 Whys principle or the if-then scenario to generate user stories and clearly relate application features to a business purpose.
Using TDD you build up, over time, a suite of automated tests that you and any other developer can rerun at will. Better Designed, cleaner and more extensible code. It helps to understand how the code will be used and how it interacts with other modules. It results in better design decision and more maintainable code.
BDD is designed to test an application's behavior from the end user's standpoint, whereas TDD is focused on testing smaller pieces of functionality in isolation.
In short it's to do with Analysis.
BDD is for "acceptance test driven development" - i.e. for knowing if a system under test behaves as expected for a specific user story scenario.
When I worked with Jbehave we used it at the user story level and still did "conventional" TDD for handling collaborations between individual objects and between subsystems.
Typically business systems use BDD scenarios to describe business domain behaviour not to test the tiny implementtion details inside the system. You want the BDD scenarios pitched at the domain expert's level of abstraction. Those scenarios wouldn't make much sense to domain experts and would be very fragile if they described every tiny detail of the implementation.
A BDD scenario says what the system should do for a user story but not how it does it.
156
BDD is about writing "executable specifications" or acceptance testing a.k.a. black-box testing which, by definition, takes an external perspective of the test object to derive test cases.
So BDD can't be about design, BDD is about testing features/stories/scenarii, BDD is closer to analysis.
27
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
