fromMarch 2013
Column:

Testing, Testing, One... Two... Three...

Getting Started with BDD
0

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.

Feature: Access account statements
  In order to manage my finances
  As an account holder
  I need access to my monthly statements

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.

Background:
  Given I am on the homepage
  And I am logged in as "Alice Account Owner"

Scenario: No existing statements
  When I follow "Your account"
  Then I should see "No statements are available"

Scenario: Access own existing statements
  And I have statements
  When I follow "Your account"
  Then I should see a list of available statements

Scenario: Access another user's statements
  When I visit "/account/42289066/statments"
  Then I should see "Access Denied"
  And I should not see a list of statements

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.

Advertisement

From our blog

Entity Storage, the Drupal 8 Way

In Drupal 7 the Field API introduced the concept of swappable field storage.

The Drupal 6 to 8 Upgrade Challenge - Part 2

Having concluded the readiness assessment, we turn next to migrating the content and configuration. In reality, there’s little chance that we would migrate anything but the blogs from our old site. For the sake of giving Migrate in Core a workout with real conditions, however, we’re going to upgrade with core’s Migrate Drupal module rather than rebuilding.

The Drupal 6 to 8 Upgrade Challenge - Part 1

Nathaniel Catchpole , the Drupal 8 release maintainer and Tag1 Senior Performance Engineer, suggested that Drupal shops everywhere could support the

DrupalCon Austin

The entertainment industry is not for the faint of heart.

Drupal Watchdog Joins the Linux New Media Family
Drupal Watchdog 6.01 is the first issue published by Linux New Media.

Drupal Watchdog 6.01 is the first issue published by Linux New Media. Come see the Drupal Watchdog team at DrupalCon 2016!

Drupal Watchdog was founded in 2011 by Tag1 Consulting as a resource for the Drupal community to share news and information. Now in its sixth year, Drupal Watchdog is ready to expand to meet the needs of this growing community.

Drupal Watchdog will now be published by Linux New Media, aptly described as the Pulse of Open Source.

Welcome to DrupalCon Barcelona - The Director's Cut

For all you schedule-challenged CEOs – and ADHD coders – this Abbreviated Official Director’s Cut is just what the doctor ordered.

Welcome to DrupalCon - The Barcelona Edition

Did we have fun in Barcelona?
OMG, yes!

Did we eat all the tapas on the menu and wash them down with pitchers of sangria?
Yes indeed!

Recursive Closures and How to Get Rid of Them

This came up while manipulating taxonomy children and their children recursively, so it’s as not far from Drupal as you’d think.