Drupal
  • Managing Successful Drupal Based Projects
  • Process
    • Team Roles and Responsibilities
    • Ceremonies
    • User Stories Best Practices
    • Glossary
  • Development Resources
    • Coding Standards
    • Setup Local Development Enviornment
    • Content Modeling
    • Git, Commit Messages & Pull Request Guidelines
    • Useful Terminal Commands
    • Package management - Composer, BLT and CI
    • Behat
      • How Behat is used in Acquia Projects?
    • Maintaining your platform/patches
  • JIRA Ticket Templates
    • Ticket Template
    • Composer Updates
    • Redirect endpoints that should not be public
    • Bug Template
    • Sync local with latest upstream code and database sprint X
    • Drupal Enablement
  • ACE & ACSF
    • Deploying to Acquia Cloud
    • ACSF - First Pull Request
    • ACSF & Drupal and Your Platform
Powered by GitBook
On this page
  • What is Behat
  • Why Behat versus Others?
  • Gherkin
  • Gherkin Syntax
  • Features
  • Scenario Outline
  • Steps
  • Tags
  • Hooks
  • Tagged Hooks
  • Multiple Context
  • Other Resources

Was this helpful?

  1. Development Resources

Behat

PreviousPackage management - Composer, BLT and CINextHow Behat is used in Acquia Projects?

Last updated 6 years ago

Was this helpful?

  • What is Behat

  • Why Behat versus others?

  • Behat Components

  • How Behat Works

  • Where used in Acquia (Behat with BLT and Lightning)

What is Behat

  • Behat is an open source Behavior Driven Development framework for PHP.

  • It is a tool to test the behavior of your application, described in a special language called Gherkin.

  • Behat integrates well with . Blt uses Behat for Functional testing. Behat comes baked in when you install a drupal site with BLT

  • Lightning, a very popular Drupal distribution by Acquia, uses Behat for all its functional testing. Both BLT and Lightning are primarily used together for client projects in Professional Services.

Why Behat versus Others?

  • Behat helps you to start developing project from “how it must behave” and not from “what concrete components it must include in particular”.

  • Clients can sign off on the tests as “acceptance criteria” for completing the project.

  • The tests are written in a human-readable text files, which can be easily extended by writing additional PHP methods

  • Non-coders can read and understand test and can help write tests.

  • It can be integrated with and other browser emulators to generate screenshots of failures.

Gherkin

Gherkin is the language that Cucumber uses to define test cases. It is designed to be non-technical and human readable, and collectively describes use cases relating to a software system. Gherkin serves two purposes: serving as your project’s documentation and automated tests.

Gherkin Example

Feature: Listing command
   In order to change the structure of the folder I am currently in
   As a UNIX user
   I need to be able see the currently available files and folders there
Scenario: List 2 files in a directory
  Given I am in a directory "test"
  And I have a file named "foo"
  And I have a file named "bar"
  When I run "ls"
  Then I should get.
"""
bar
foo
"""

Gherkin Syntax

  • Gherkin is a line-oriented language that uses indentation to define structure.

  • Line endings terminate statements (called steps) and either spaces or tabs may be used for indentation.

  • Finally, most lines in Gherkin start with a special keyword ( Feature, Scenario.. etc)

  • The parser divides the input into features, scenarios and steps

In Gherkin, each line that isn't blank has to start with a Gherkin keyword, followed by any text you like. The main keywords are:

  • Feature

  • Scenario

  • Given, When, Then, And, But (Steps)

  • Background

  • Scenario Outline

  • Examples

There are a few extra keywords as well:

  • """ (Doc Strings)

  • | (Data Tables)

  • @ (Tags)

  • # (Comments)

Features

A feature is a Use Case that describes a specific function of the application being tested. There are three parts to a Feature:

  • The Feature: keyword

  • The Feature name (on the same line as the keyword)

  • An optional description on the following lines

Feature: Withdraw Money from ATM A user with an account at a bank would like to withdraw money from an ATM. Scenario: Scenario 1 Given preconditions When actions Then results Scenario: Scenario 2 ...

Scenario: John wants to withdraw money from his bank account at an ATM
    Given John has a valid Credit or Debit card
    And his account balance is $100
    When he inserts his card
    And withdraws $45
    Then the ATM should return $45
    And his account balance is $55
    
Background:
Given John has an account with ABC Bank
And his account is in working state

Scenario: John wants to withdraw money from his bank account at an ATM
    Given John has a valid Credit or Debit card
    And his account balance is $100
    When he inserts his card
    And withdraws $45
    Then the ATM should return $45
    And his account balance is $55

Scenario Outline

Scenario Outline: A user withdraws money from an ATM
    Given <Name> has a valid Credit or Debit card
    And their account balance is <OriginalBalance>
    When they insert their card
    And withdraw <WithdrawalAmount>
    Then the ATM should return <WithdrawalAmount>
    And their account balance is <NewBalance>

    Examples:
      | Name   | OriginalBalance | WithdrawalAmount | NewBalance |
      | John   | 100             | 45               | 55         |
      | Greg   | 100             | 40               | 60         |
      | Ed     | 1000            | 200              | 800        |

Steps

A step typically starts with Given, When or Then. If there are multiple Given or When steps underneath each other, you can use And or But.

  • Given - The purpose is to put the system in a known state before the user starts interacting with system.

  • When - Describes the key action the user performs.

  • Then - Describes the outcome resulting from actions taken

  • And - Logical and

  • But - Logically the same as And, but used in the negative form

Scenario: John wants to withdraw money from his bank account at an ATM Given John has a valid Credit or Debit card And his account balance is $100 When he inserts his card And withdraws $45 Then the ATM should return $45 And his account balance is $55

As set of features will grow, there’s a good chance that the amount of different steps that you’ll have at your disposal to describe new scenarios will also grow.

Behat provides a command line option --definitions or simply -d to easily browse definitions in order to reuse them or adapt them. Existing Behat Steps can be discovered from the CLI.

$ #just list definition expressions $ behat -dl $ #show definitions with extended info$ behat -di

./vendor/bin/behat -dl -c tests/behat/local.yml -p local

Tags

Tags are a great way to organize your features and scenarios. These can be placed before:

  • Feature

  • Scenario

  • Scenario Outline

  • Examples

A Scenario or Feature can have as many tags as you like, just separate them with spaces. @billing Feature: Verify billing @important @product Scenario: Missing product description

Hooks

Behat hooks are a simple way to execute your custom code just before or just after each of Behat events/action occurs.

Behat allows you to use the following hooks:

  • BeforeSuite This hook is run before any feature in the suite runs. For example, you could use this to set up the project database you are testing.

  • AfterSuite This hook is run after all features in the suite have run. This hooks is useful to dump or print some kind of statistics or tear down your application after testing.

  • BeforeFeature This hook is run before a feature runs.

use Behat\Behat\Hook\Scope\BeforeScenarioScope;
use Behat\Behat\Hook\Scope\AfterScenarioScope;

/** @BeforeScenario */
public function before(BeforeScenarioScope $scope){
  $this->getSession()->resizeWindow(1200, 786);  
}

/** @AfterScenario */
public function after(AfterScenarioScope $scope){
}

Tagged Hooks

Sometimes you may want a certain hook to run only for certain scenarios, features or steps. This can be achieved by associating a @BeforeFeature, @AfterFeature, @BeforeScenario or @AfterScenario hook with one or more tags. You can also use OR(||) and AND (&&) tags:

/**
 * @BeforeScenario @database&&@fixtures
 */
public function cleanDatabaseFixtures()
{
    // clean database fixtures
    // before @database @fixtures
    // scenarios
}

Context

Context classes are a keystone of testing environment in Behat

The context class is a simple POPO (Plain Old PHP Object) that tells Behat how to test your features.Feature tells how your application behaves, then the context class is all about how to test it.

Feature Context

/**
 * @When I do something with :argument xyz
 */
public function iDoSomethingWith($argument){
    // do something with $argument
}

Then I do something with user xyz

Multiple Context

# behat.yml
default:
    suites:
        default:
            contexts:
                - FeatureContext
                - SecondContext
                - ThirdContext

RawDrupalContext A context that provides no step definitions, but all of the necessary functionality for interacting with Drupal, and with the browser via Mink sessions.

DrupalContext Provides step-definitions for creating users, terms, and nodes.

Other Resources

Scenario Scenario is defined by a sequence of Steps outlining the preconditions and flow of events that will take place. Every scenario starts with the Scenario: keyword (or localized keyword), followed by an optional scenario title. Each Feature is made of a collection of scenarios and every scenario consists of one or more .

Mink Mink is an open source browser controller/emulator for web applications, written in PHP 5.3. PhantomJS PhantomJS is a scripted, used for automating web page interaction. PhantomJS provides a API enabling automated navigation

BLT
Selenium
Steps
headless browser
JavaScript
“What’s in a Story?” by Dan North’s
Behat.org
Mink.behat.org
Behat Cheat Sheet
Drupal Behat Extension
Automation Testing & BLT