Behat Steps, ready-made Behat test steps for Drupal
The tests every Drupal project writes twice: logins, content, email, logs
Automated tests for a website are usually written in near-English, a sentence per action. "Given I am logged in as a user with the administrator role." "Then an email should be sent to the applicant."
That is deliberate: the people who decide what a site must do can read what is being checked.
Behind each of those sentences sits real code. Someone has to implement, in PHP, what "logged in as an administrator" means, what counts as an email being sent, and how a test knows a file actually downloaded.
And the sentences repeat from project to project:
- sign in as a role
- create content
- check an email went out
- confirm nothing landed in the site's error log
Writing them the first time costs a few days. Keeping them is the part nobody budgets for.
They live in your repository, and they need attention every time Drupal(Opens in a new tab/window) moves. They are never what your project is actually about, and when they break, testing quietly stops.
A library you take a piece at a time: Behat steps as PHP traits
behat-steps(Opens in a new tab/window) is that set of steps, written once, tested and maintained. It ships as PHP traits, so a project imports the pieces it wants and nothing else.
Take the email assertions without inheriting anything you did not ask for, and keep every step your team has already written sitting alongside them.
Small parts rather than a single base class is what makes the library safe to adopt gradually. You add a piece, nothing you had before changes, and you decide about the rest later.
It covers the common ground of Drupal testing:
- authentication and roles
- content
- file downloads
- media
- error-log checks
For a client, that reads as a shorter start: the test suite on your project begins with the common ground already written and already maintained.
Where it came from: a Drupal test context cut from 300 lines to 46
It started on a real project in 2018, a Victorian government health department website reached through a government digital agency.
That project had built itself a thorough set of test steps:
- email assertions
- file downloads
- media handling
- error-log checks
All of it solid work, and none of it specific to a health department.
So we pulled the generic parts out into a package we would maintain. The project's own test class went from roughly 300 lines of bespoke step definitions to 46 lines that simply compose the imported ones, with every check it had before still in place.
The department kept its coverage and stopped owning the plumbing underneath it. Every project we have worked on since has had those steps for free.
The decisions that make it safe to rely on: strict error-log checks
A library like this earns trust in the details. Checking Drupal's error log after every scenario is the classic source of false alarms, because some scenarios are supposed to trigger an error.
The easy answer is to soften the check for everyone. Instead, a test can declare that it expects an error, so the check stays strict everywhere else.
Sometimes the behaviour that needs adjusting sits further upstream, in the shared Drupal testing driver the library builds on. When that is the right home for a fix, it goes there rather than being worked around on every project, and we have been contributing to that driver for years.
Where it ended up: whole-of-government Victoria and community radio
A library extracted from a single health department project went on to underpin the Victorian Government's Single Digital Presence, the shared platform behind vic.gov.au and the agency sites around it. Years later it was doing the same job on a community radio station's rebuild.
It ships as part of Vortex(Opens in a new tab/window), our open-source Drupal project template, so every project we start inherits it.
It has been maintained since 2018, across Drupal 7 through to Drupal 11, which is a long time for a package to stay useful in a platform that changes as much as Drupal does.
300 lines of test glue became 46 lines of composition, and a package maintained since 2018 across Drupal 7 to Drupal 11.
It also carries contributions from developers with no connection to DrevOps. People do not send patches to code they are not depending on.
For a client, that track record is the point: the steps your suite depends on have outlived the projects that introduced them.
What it adds up to: Drupal testing that starts already built
The library is public, so any Drupal team can use it without ever talking to us. Testing gets skipped when it is expensive to start, and the quickest way to make it cheap is to stop asking every project to rebuild the same foundations.
When we take on a platform, that groundwork is already done and maintained. The effort goes into the parts that are actually yours.
For teams rewriting the same Drupal test steps
Everything on this page is 2 of our services pointed at our own tooling: development of the library, and the ongoing support and maintenance that has kept it current from Drupal 7 through to Drupal 11. The same standard applies to our AI-assisted delivery: however fast the code arrives, the automated checks are what decide it is safe to ship.
If you run a Drupal site whose test suite nobody wants to open, or a team writing the same step definitions on every new project, this is the shape the engagement takes. The generic steps come from a maintained library, your own steps sit beside them, and the only checks you own are the ones specific to your business.
If your last Drupal upgrade was verified by hand because nobody trusts the automated suite, tell us what it covers today.