Join Robin Beck for an in-depth discussion in this video Review, part of Behavior-Driven Development.
- [Instructor] Let's take a moment to review how Cucumber, our BDD framework, assisted us in implementing our scenario. We came to Cucumber with a concrete example of our acceptance tests already written. It was helpful that we chose to phrase our acceptance criteria in scenario format using the Given, When, and Then keywords that can be parsed by the Gherkin language. If our scenario was less concrete, it would have been difficult to test the application in the beginning.
Scenarios that don't use examples of names or context make it harder to test in the long run. By having concrete examples of our customer, Maria, and our associate, Li, and a price that Maria is charged, as well as an idea of the domain model that our scenarios need to function correctly, we set our examples up for continued automation later on. Now of course we're just starting out with the development process.
I was able to force my assertion to pass pretty easily. And this just reinforces that our tests need more work. Once we introduce further complexity to the system, we'll want to write a more robust set of scenarios that help further define the implementation. For example, if I make a simple change, like maybe changing the card minimum to one. Re-running Cucumber. My tests break. The fact that there's such a close coupling between the scenarios and the implementation means that I need to do more domain modeling and most importantly, write more tests.
I can start by being more specific with my scenarios. Perhaps by adding another step using the Gherkin keyword, and. Beneath the Given statement, I could state that Given Maria orders $3 of coffee from Li, and, the total charge is over the card minimum. Running Cucumber, I'll now have another undefined step. And I can use this snippet to continue my domain modeling. But at its heart, this is what Behavior-Driven Development is all about.
Examples of how the application behaves inform the development. Assuming that our examples have been crafted from clear communication of requirements from the beginning. The BDD framework can even help us understand when our examples might not be concrete enough. But it's the process of exhausting examples and revisiting requirements regularly that allow the BDD cycle to continue, reducing the translation costs from the business interests to the developers as much as possible.
True to Agile, the only constant in this process is change. Your business requirements will change, the technologies you use will change. And your client's needs will change. This type of testing with Cucumber and other BDD frameworks allows us to describe our unit tests as examples of how parts of the system need to behave while avoiding coupling our tests directly to the code. This way, as our requirements change and we need to modify the underlying functionality, we can safely make big changes to the way something works while maintaining the integrity of how the system behaves.
- What is behavior-driven development?
- Agile and BDD
- BDD examples
- BDD frameworks
- Defining scenarios
- Domain modeling
- Enforcing object-oriented design
- BDD process: Behavior before function