We’ve been working with Behat for one of our clients. It’s a wonderful technology that implements Behavior driven developmentΓö¼├í(BDD) to increase the understanding between the customer and the software developer implementing the solution. It applies a testing based approach to software development. At the very beginning of development, test cases (in a language called Gherkin) are written. A software is only considered complete if it meets and passes these test cases.

We’ll be writing a series of posts to share our knowledge, starting with basic description of some important concepts related to Gherkin and Behat. A sample test case written in Gherkin for Behat could look something like this-

Feature : Logging in

In order to use the application I need to be able to log in

Background:

Given I am on the homepage

Scenario:

When I enter”osmosys” in the textbox”username”

And I enter”password” in the textbox”password”

And I press the button”Login”

Then I should see”Welcome, osmosys”

Each sentence of the test case is called a step.

Other than that, there are three main parts of the test case.

• Γö¼├í Γö¼├í Γö¼├íFeature – Describes what we are planning to do with this test case.
• Γö¼├í Γö¼├í Γö¼├íBackground – This consists of steps that will be run before every Scenario.
• Γö¼├í Γö¼├í Γö¼├íScenario – This contains the steps that will perform the tests. Each Scenario should be aimed to complete one part of the test – such as logging in, sending a mail etc.

You’ll notice that each step starts with either Given, When, Then, And –

• Γö¼├í Γö¼├í Γö¼├íGiven – This puts the system in a known state. In the above example, The system is on the homepage. It’s like an assertion.
• Γö¼├í Γö¼├í Γö¼├íWhen – This denotes an action that maybe performed by the user. Pressing a button, filling a field etc.
• Γö¼├í Γö¼├í Γö¼├íThen – This denotes the result of an action and is written to perform checks.
• Γö¼├í Γö¼├í Γö¼├íAnd – Multiple “Then” or “When” can be combined using And.

Behat doesn’t care what order you put your steps, but you should. The idea is that these keywords should form a structured order of steps.

These steps are put inside something called a feature file which is basically a file with an extension of “.feature”. A single feature file can contain multiple Scenario(s). This is where Background really helps. Any changes that may have been made by a Scenario can be reset using the Background before the next Scenario runs. The steps in the feature file above are fairly explanatory.

This test case can be used to check if the login functionality of your application works properly.

In addition to these we have another important keyword – Scenario Outline

Let’s write another test case to show how Scenario Outline are helpful.

Feature : Checking content on products page

Verify that the correct content is shown for various products

Background:

Given I am on”/Products.aspx”

Scenario Outline:

When I click on”<product_name>”

Then I should see”<product_heading>”

And I should see”<product_content>”

 Examples:

|product_name|product_heading|product_content |

| Scrinter      | Scrinter  |screen monitoring tool|

| Pallaaki      | Pallaaki         |data exchange simple and easy to use|

Scenario outlines are used to run the same step with multiple arguments. So first time the scenario outline runs it’ll substitute product_name with”Scrinter”, product_heading with”Scrinter” and product_content with”screen monitoring tool”. The second time the second row in the example table will be run. Before the execution of each row in the example table, the steps specified in Background are run.

There is a reason that these files are called feature files. It’s because they are supposed to represent/test a feature of your application. These steps are quite easy to write so a customer with very little technical knowledge can write them.

Now with that background information in our hands, our next post will talk about setting up Behat and automating testing using these feature files.