Automated tests must be instrumented with executable code and maintained by developers, which is a common problem. Often they are not even understandable by people without a developer background. On the other hand only a few people, who know the business case, have this special knowledge. Therefore the majority of potential testers cannot be directly involved in creating automated test cases that describe the business of the customer. This problem is addressed by the „cucumber“ BDD framework.

In „cucumber“, test cases are defined in text files called „feature files“. They contain exactly one „feature“ with one or more „scenarios“. The scenarios follow the BDD pattern of given, when, then to define „steps“ that must be taken to complete the test case. Feature files can contain additional comments or descriptions. They can even be localized in different languages. Below an example of a feature file

Feature: Browse OC Website

Scenario: Test navigation to "Über uns" page
      	Given I visit the website ""      
      	When I click "ÜBER UNS"
	Then I see the page with the title "Über uns"

But how does the text above end up as an automated test? The solution is called the „gherkin parser“ which parses the feature files and tries to find matching code for each line starting with one of the keywords. In our case keywords are defined as „Given“, „When“ and „Then“. The programmatic code to execute the actual test is called „step definition“ and can be written in many different programming languages. The following example is written in Java.

public class MyStepDefinitions{

      @Given("I visit the website \"([^\"]*)\"")
      public void openWebsite(String site){

      @When("I click \"([^\"]*)\"")
      public void clickLink(String link){

      @Then("I see the page with the title \"([^\"]*)\"")
      public void checkPageTitle(String title){

The Java example above uses a single JUnit Test Class to run all the Features.

Public class CucumberTests{

Of course the test code itself has to be implemented using an appropriate framework. For our current example, where the test is navigating on a website, this could be „WebDriver“. In other cases it might be something else. In summary „cucumber“ provides a way to keep the specification of the tests in plain text. This way the test can be maintained by those who understand the business case and contains no instrumentation code like it is used in many other BDD frameworks. More examples, other features of „cucumber“ and descriptions of how to add the required libraries to your project can be found on the cucumber website:

Alle Beiträge von marcelsoulieropitzconsultingcom

Schreibe einen Kommentar