This project is not covered by Drupal’s security advisory policy.

There is an open security issue: [META] Testing coverage: Security section

Doobie is the home of Behavior-Driven Development. Tests are specific to D.O. See the Drupal Extension to Behat and Mink if you're looking for a tool to assist in testing Drupal sites in general.

Software requirements to run tests:

This project requires the following, installed on the system running the tests. If you don't set these up, see the error messages you'll get at

Set up instructions:

  1. Clone this repository
  2. In the repo root, install Composer, a PHP Dependency Manager:
    curl -s > composer.phar
    wget -nc
  3. Run the composer install command:
    php composer.phar install
    Note: This takes a little while before you start seeing any output.
  4. Copy behat.local.yml.example to behat.local.yml, making sure you're pointed at the base host you intend. You'll use this file to store settings that reflect your local environment, credentials, and other settings which don't belong in the repository.

    Note: If you have not already received the testing passwords, request them in the issue queue.

  5. Verify behat is properly installed and see defined steps
    bin/behat -di

Running tests

  1. Start selenium and leave it running in its own terminal window. (Not all tests use it, but you'll need it for the ones tagged @javascript or you'll get an error.)
    java -jar /path/to/selenium-version-whatever.jar
  2. Run tests. Below are examples of different ways to select the tests you want:
    • Exclude known failures, incomplete tests, and tests requiring privileged access:
      bin/behat --tags="~wip&&~known_git6failure&&~api"
    • Run all tests:
    • Run only javascript tests
      bin/behat --tags="javascript"

See for more detail on using tags.

D7 QA process

Code is integrated on and tests are run against that site either from a local test install or, as a part of continuous integration, from

  1. When a test fails, QA opens a "Failing test" issue
  2. QA investigates and marks as "Test needs update" or "Broken site"
  3. CI moves the issue to the appropriate queue and may choose to postpone, inactivating the test by adding the @wip tag

"Broken site" issues:

  1. Developer commits a fix in bzr -> sets issue to "Needs review"
  2. QA verifies commit is deployed and re-runs test, sets to "needs work" or "reviewed & tested by the community" as appropriate
  3. CI marks as fixed or sets back to "needs work"

"Test needs update" issues:

  1. QA person updates test
  2. Second QA person verifies test is working
  3. Sets to "needs work" or "reviewed & tested by the community" as appropriate
  4. CI marks "fixed" or sets back to "needs work"

Documentation is available at

Project information

  • chart icon813 downloads
  • shield alertThis project is not covered by the security advisory policy.
    Use at your own risk! It may have publicly disclosed vulnerabilities.