Behavior Driven Development with JUnit 5. Part 6
-
Share:
-
-
-
To run the Cucumber tests, we’ll need a special class. The name of the class could be anything; we choose CucumberTest.
[...]
@RunWith(Cucumber.class) #1
@CucumberOptions( #2
plugin = {"pretty"}, #3
features = "classpath:features") #4
public class CucumberTest {
/**
* This class should be empty, step definitions should be in separate classes.
*/
}
In this listing:
- We annotate the class with @RunWith(Cucumber.class) #1. Executing it like any JUnit test class runs all the features found on the classpath in the same package. As there is no Cucumber JUnit 5 extension at the moment of writing this chapter, we use the JUnit 4 runner.
- The @CucumberOptions annotation #2 provides the plugin option #3 that is used to specify different formatting options for the output reports. Using "pretty", the Gherkin source is printed with additional colors (figure 7). Other plugin options include "html" and "json", but "pretty" is appropriate for now. And the features option #4 helps Cucumber locate the feature file in the project folder structure. It looks for the features folder on the classpath—and remember that the src/test/resources folder is maintained by Maven on the classpath!
By running the tests, we see that we have kept the test functionality that existed before moving to Cucumber.
Figure 7. Running CucumberTest. The Gherkin source is pretty-printed, successful tests are displayed in green, and the code coverage is 100%.
There is another advantage of moving to BDD. Comparing the length of the pre-Cucumber AirportTest class (see our series of articles dedicated to TDD), which has 207 lines, with the PassengersPolicy class, which has 157 lines, the testing code is only 75% of the pre-Cucumber size but has the same 100% coverage. Where does this gain come from? Remember that the AirportTest file contained seven classes on three levels: AirportTest at the top level; EconomyFlightTest and BusinessFlightTest at the second level; and, at the third level, two RegularPassenger and two VipPassenger classes. The code duplication is now really jumping to our attention, but that was the solution when we only had JUnit 5.
With Cucumber, each step is implemented only once. If we have the same step in more than one scenario, we’ll avoid the code duplication.
Conclusions
This article has covered the following:
- Introducing BDD, a software development technique that encourages teams to deliver software that matters and supports cooperation between stakeholders
- Analyzing the benefits of BDD: addressing user needs, clarity, change support, automation support, focus on adding business value, and cost reduction
- Analyzing the challenges of BDD: it requires engagement and strong collaboration, interaction, direct communication, and constant feedback
- Moving a TDD application to BDD with the help of Cucumber by creating a separate feature, generating the skeleton of the testing code, writing the tests, and implementing the code
Tudose, Florin-Catalin Tudose
