About Behavior-Driven Development

In behavior-driven development (BDD), you start software development from defining how the application should behave. The person who is responsible for the development decides what features must be implemented and creates the so-called feature stories that contain a description of each feature and an example of how users will use it. That person uses regular language constructions that look like regular text, so that any team member can read and understand it.

Then QA engineers or development testers create test steps that run the application, simulate user actions and so on. To create test steps, they can use TestLeft that helps them explore the application, write code and run tests.

Normally, features are described in text files by using the Gherkin syntax. Usually, one file contains a description of only one feature and any number of scenarios:

Click the image to enlarge it.

The file starts with the Feature keyword followed by a colon and the feature title. The next few lines contain a short feature description (narrative). There are no strict rules for writing narratives, but it should include a short feature description, a user role and a benefit.

Each scenario starts with the Scenario keyword followed by a colon and the scenario title. A scenario consists of the following blocks:

• Given – declares the initial state of the scenario. At this step, you prepare the testing environment.

• When – declares testing actions.

• Then – verifies the result of the performed actions.

Each block is a line starting with the corresponding keyword. You can use more than a one line for each block. In this case, use the And or But keyword.

To learn more about writing stories, see the Gherkin reference.

When a test is running, the BDD framework is looking for the matching step definition for each test step specified in the feature file. A step definition may be different depending on the BDD framework and on the programming language you use, but in general, it looks like this:

Click the image to enlarge it.

As you can see, a step definition is a combination of the following:

• An annotation that corresponds to a test step keyword.

• A regular expression that matches the text of the test step.

• A method that performs the actual testing actions: runs the application, simulates clicks, enters text, verifies the result and so on.

Most BDD frameworks can generate code stubs for step definitions.

When you implement a test step, you create a method for a step definition that will simulate user actions. TestLeft helps you both create the required code and execute the simulated actions.

In general, you create a BDD test with TestLeft in the same way you create any other TestLeft test. If you want to learn more about it, see Using TestLeft. Note, however, that in BDD tests, each test step is a separate test method. To pass a reference to test objects through the steps, make sure you use objects that are visible for all test methods.

To learn more, see Your First BDD Test With TestLeft.