Skip to main content
Ungathered Thoughts

Behat, Drupal and related tools

This is really a brain dump for a developer joining one of many projects I'm using Behat, Drupal & some related tools on at the moment. But ... if I write it up generally instead of as a stream in some chat program, it won't be lost quite as quickly. Or I can link to it next time.

First of all: Why Behat? For me, after a few times clicking through the same webform, I start to feel a little ... impaired. Seriously. I cannot manually test effectively; my brain is gone elsewhere. But that's fine, because repetitive manual testing is not something we need humans to be doing, and we can deliver it repeatably and reliably for Drupal using Behat.

Behat abstracts the steps of testing into Feature and Scenario definitions written in Cucumber syntax. I recommend absorbing the way that Cucumber / Gherkin is written 1, 2,

Scenario: Wilson posts to his own blog
  Given I am logged in as Wilson
  When I try to post to "Expensive Therapy"
  Then I should see "Your article was published."

The Steps in the Scenario above (and the associated components like Feature, Background etc) describe in plain language how something is used.

Developing with Behat

What's ideally going to happen in your development cycle looks like this:

Understanding Behat structure

+ composer.json
  + tests
    + behat
      - behat.yml
      - features/bootstrap/FeatureContext.php
      - features/*/foo.feature

composer.json - In composer.json we reference composer libraries for Behat, and a set of other supporting components. Some of these might be:

Install Behat libraries using composer require --dev so they don't get sent to production.

behat.yml - This is the configuration file for Behat. It has configuration sections for Behat packages, and supports multiple profiles so you can (for example) switch profiles for different environments. It can sprawl a bit, but mostly you won't need to change it.

features/bootstrap/FeatureContext.php - each project has a FeatureContext like this, although you can add your own custom contexts either in the Behat directory or as extensions. For example, if you had a set of sites to test together you could create an BauersiteContext class which encapsulated functionality specific to that suite of sites.

features/*/foo.feature - this is where the Features live. Organise as you wish (if they don't auto-load, check the top of your behat.yml). Tag your features and use tags to run specific features: behat --tags=@payment. I often tag tests with the associated WR during development, so I can behat --tags=@wr277853.

Writing good Scenarios

Good blog posts / docs / videos

To do

Things I could expand on more here.