Join Robin Beck for an in-depth discussion in this video Define the scenario, part of Behavior-Driven Development.
- [Instructor] When writing cucumber code, our concrete examples are called scenarios, which are defined in dot feature files that live inside of the features directory. Let's create our first feature file by right clicking on the features directory and opening a new file. I'll save the name of this file as card_mimimum.feature. Feature files should always start with the Gherkin keyword Feature.
Placing a colon after this keyword, I can follow it with a name. It's usually considered best practice to match the feature name to the name of the file so you can understand where the test came from. We'll call this feature Card Minimum. Now, we can add our first scenario. Coming down a couple of lines and indenting with a tab, I'll type Scenario, colon, Total charge is over the two dollar credit card minimum.
Remember that this concrete example comes from our three amigos conversation from earlier. We can now use the Gherkin key words to drive out this scenario in detail. These key words were Given, When and Then. Given that Maria orders three dollars of coffee from Li. When Maria pays with a credit card, Then Li should process the payment.
I'm gonna save this file and head back into my terminal session where I'll now run cucumber. Scrolling through the output up to the top I can see that it prints the scenario. It mentions that we have one scenario that's undefined and three steps that are undefined. And that we can implement step definitions for the undefined steps with the snippets that are printed as output below. Step definitions will help us translate the human readable language used in the feature file into code for our application.
- 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