This article inaugurates a regular column for Drupal Watchdog on incorporating functional testing and Behavior Driven Development in the creation and maintenance of Drupal Sites..

If my Behat and Mink article in the previous DW piqued your interest in using Behat as a functional testing tool, you may be wondering where to begin. Dan North’s article outlining the origins of Behavior Driven Development (http://dannorth.net/introducing-bdd/) provides a more complete perspective, but the short answer is:

What parts of your site have the highest value to your organization?

If it’s not immediately apparent, turn that question on its ear:

Which parts of the site, if broken, will result in:

• Loss of revenue (e-commerce);
• Loss of productivity (a broken work order form);
• Law suits (privileged information being disclosed publically)?

Having conversations with others on your team, conversations to ensure you’re building and testing the right things, is at the heart of Behavior Driven Development — so be sure to discuss these issues with your team.

Install the Tools

Next, install the tools on your local machine. Eventually, you’ll run tests on a server and integrate them with your team’s workflow, but that can wait. Right now, learn about and run these tests from your own desktop. That’s a little easier if you follow these Drupal-specific directions: http://www.dspeak.com/blog/drex-new

Choose a Feature

From all the high-value features on your site, pick one that looks clear and easy. A common and extremely valuable feature on Drupal sites is providing privileged access to certain content. This can also be a vulnerable point: misconfigurations are common; hand verification is tedious and time consuming; and it’s easy to miss rebuilding permissions after certain updates.

Once you've chosen a feature, describe how the application behaves in different scenarios. Each sentence in a file is called a step, and you can find steps that are already automated by typing bin/behat -dl. Anywhere you see something in quotes, you can input your own values.

What if I Can’t Find the Step I Need?

Users interact with web sites by employing a lot of common actions; clicking and filling and seeing an outcome. Chances are, though, that if you’re focusing on value, most of your features will require writing some PHP in order to automate steps. BDD's use of every-day language is not intended to minimize the role of developers, but to focus their efforts on functionality that matters by facilitating everyone’s understanding. You’ll need your developers to support automation. The bonus of using Behat in Drupal shops is that both Drupal and Behat are written in PHP, so your development staff can participate immediately.

Run Your Tests

As you learn, you’ll realize there are different ways to use your automated tests. Using the Drupal Extension to Behat, you can choose to run you tests in one of three ways:

• Black box — Run against a site where you cannot set up and tear down data willy-nilly (e.g., Production)
• Drush — Put the site in a known state using Drush (which works regardless of whether the tests are on the same server as the site).
• API — Use Drupal API to put the system in a known state. (Site and tests must be on the same system)

Resist the Urge to Test Everything

There are an infinite number of tests you could write for a Dupal site. Most take time to run, time to update, and time to interpret their failures. Focus on valuable features that were created by your site's specific configuration, not those provided by Drupal itself. For example, I would not ordinarily write tests for adding users, or allowing them to request new passwords, unless those features had been customized or had unusually high business value.

Run the Tests Over Time

Check to see how well you’ve done on your first tests by running them after the modules that affect your features have had a security release or, even better, a version upgrade. You could even simulate by downgrading the modules. Do the tests break when they’re supposed to? Do they break when they shouldn’t?

A small, well-written test suite can provide a huge return on the investment in learning and using these tools, even if you never take it further. More than likely, you’ll then be fully prepared for the next phase: incorporating tests with continuous integration systems or as gates in your deployment process.