Drupal Behat Course - Behavior-driven development (BDD)

Each type of test covers a different level of the product: unit tests check the smallest parts of the code, functional tests that a specific feature does what it should, and acceptance tests that the product meets the business requirements. The latter are the ones the client can read, understand and validate. We also look at when automating pays off and when it does not.

In BDD, tests are derived directly from business requirements written in plain language, so that business and technical teams start from a shared understanding of how the product should behave. Scenarios work both as automated tests and as living documentation: when a requirement changes the scenario changes, and whatever is not updated does not pass the tests.

We turn abstract requirements into verifiable behaviors. Starting from the "as a… I want… so that…" format, we add what makes a scenario checkable: preconditions, post-conditions, alternative scenarios and error cases. We close with the difference between verifying (the system does what the specification says) and validating (that this is what the business actually needed).

Behat is the tool that runs the scenarios: BDD is the methodology, Gherkin the language the scenarios are written in, and Behat the engine that reads them and checks them against the real system. It is a natural fit for PHP environments and widely used in Drupal projects, because there are ready-made steps for nodes, users, permissions, forms and views. Mink is what decides whether a scenario needs JavaScript or not.

We take a .feature file apart piece by piece: the feature describes the functionality being validated, the scenario a specific case within it, and the Given/When/Then steps the actions and expected results. From there, the tools that keep you from repeating yourself: backgrounds for shared context, scenario outlines to run the same scenario with several sets of data, and variants for error cases.

First hands-on block: we set up the testing machine and write scenarios against real cases, from basic access and error checks to content visualization and navigation and forms, including those that depend on JavaScript. The rule throughout is to keep only the steps that check a real behavior and drop the decorative ones.

We install Behat with Composer on a DDEV environment and go through the packages that make it work on Drupal: behat/behat as the runner, behat/mink and its extension to interact with the browser, the matching drivers, and drupal/drupal-extension, which provides the Drupal-specific steps. With that in place, the practical decision is when a headless emulator is enough and when you need to drive a real browser.

behat.yml is where everything is declared: the suites, the contexts that provide the available steps, the extensions and the environment base URL, with separate profiles so you do not have to touch the main configuration when switching environments. We also look at where features and contexts live inside the project, and how to load the DrupalExtension contexts alongside Metadrop own library (metadrop/behat-contexts), which adds debugging and screenshot utilities.

We run the suite and learn to read the output: steps that pass, that fail, that stay pending because no definition matches them, and that are skipped because an earlier step failed. From there you can filter by tags or check the setup with a dry run. When no existing step fits, you write your own in the project context — with parameters, leaning on the Drupal API and on XPath — keeping the reusable ones in shared libraries instead of piling them into FeatureContext.