An Introduction to behat & BDD

Origins of BDD (Behaviour Driven Development)

This derives from TDD (Test Driven Development) which is very similar but focuses more on unit tests and smaller parts of the software whereas BDD will be used to work on the bigger processes you might expect to have in the software you are developing. BDD also concentrates on how the software should actually behave. Before the software is actually built you would first need to define how the end user would actually use the software once it is complete, it could be as simple as working out how a user would log in.

3 Amigos

This form of testing makes it so all parties involved in development will be able to communicate a lot more as it makes it easier for everyone to understand as everyone would not need to understand PHP etc. which will allow them to work closer together. Whenever software is being designed and created there should be 3 parties involved. This will consist of customer,developer and tester this is also known as the 3 amigos.

Customer > Developer > Tester

User stories

A user story is defined by wikipedia as "an informal, natural language description of one or more features of a software system."

The user stories would need to cover what the software would ultimately need and be expected to do. This is something which a user would be able to do on their own but usually all the 3 amigos help to offer different views. You will see an example of this further down which we have referred to as "feature".

Gherkin

Before we dive into talking about user stories and scenarios, We should discuss Gherkin which is the language that Cucumber understands. This language allows you to describe the behaviour of the software you are working with, without having to go into too much detail on how things would be implemented and developed.

Scenarios

Scenarios are used to define what the software will need to do and how the user/customer will actually use it. This will need to be in quite a bit of depth to cover all bases. An example of this would be how a user/customer would log into the software if it is required.

Before actually going away and writing your own scenarios we will first need to cover how they would actually be structured and what they should look like.

Below you will see a template of how you would usually find them.

Feature: 
    As a [Role]       
    I need to [Feature]
    In order to [Benefit]

Scenario: 
      Given [Context]
      When [Event]
      And [Additional Event]
      Then [Outcome]

Now you should have an idea of how scenarios should be structured and what should be included in everyone you create. It is now time to look at how we would write a scenario for a simple log in process which we mentioned earlier.

Scenario Example

Feature: A user needs to access the system 
      In order to access the system 
      As a user 
      I need to be able to log in 

Scenario: The user can log in 
      Given I am on the login page
      When I fill in the following:
         | UserName   | admin        |       
         | Password   | password     |
      And I follow "Log In"
      Then I should see "Sign Out"

The above example is just one of many different ways you would test your software. The reason we would need to go into such depth is to cover all bases.

What happens if everything is fine I.e login/password What happens if email is incorrect? Will they be prompted with a forgot password icon or any form of indication it is incorrect? The ability to create an account if one is needed What happens after 3 failed login attempts i.e captcha/ lock out?

By adding in the above you will cover a lot more of the issues a user might face when attempting to log in. This will have a positive impact on the software as this will decrease the amount of issues you could face.