Accueil / Blog / Métier / Archives / Running tests with Drupal

Running tests with Drupal

Par Benoit Bryon — publié 07/12/2011, édité le 25/01/2016

Here are some notes about running tests with Drupal 7, using bundled scripts/ or drush.

Prerequisites: system setup

To try this article, you need:

  • a Drupal 7.x installation;
  • drush.

System setup is not covered by this article.

In the following article, let's say:

  • we got a Drupal 7.x website running at
  • we got drush installed and "drush" command is in the shell's PATH
  • we execute commands from Drupal root.

Create Drupal tests: example with the predictable_tests module

The creation of Drupal tests is not covered by this article.

You can follow simpletest module documentation [1].

In this article, we are to use the predictable_tests [2] module. It registers tests that always or never pass. We will use these tests to:

  • try tests that passes and others that fails;
  • use "quick" tests. Standards tests bundled with Drupal or simpletest are quite slow to run. So predictable_tests will save us time.

Install simpletest

# Download and install simpletest
drush dl simpletest
drush en simpletest

Install modules to test (here: predictable_tests)

Predictable_tests is currently at "sandbox" stage on, so you can't (or I don't know how to) download it with drush. So let's fetch it manually from Github:

# Download and install predictable_tests manually
git clone git:// sites/all/modules/predictable_tests
drush en predictable_tests

Set English as default language

There currently are issues in simpletest: testrunner fails if you don't use Drupal's default builtin language (i.e. English).
In development or integration environments (i.e. *do not do this on production!*), you can use the drush_language module:

drush dl drush_language
drush en drush_language
drush language-default en

And don't forget to switch back to the former default language later...

Running tests with scripts/

Let's consider some examples using script bundled with Drupal... We will see how to reproduce these actions with Drush later.

Notice that:

  • is not a SH script, but a PHP one!
  • If --xml folder does not exist or is not writeable, you get no errors!
  • In my case, I had to specify the php interpreter, even if:
    • "which php" returns the good result
    • I execute the command with the php interpreter, so I'd like it recognized himself...
php scripts/ --php /usr/bin/php PredictableTests
# 1 fail, 2 pass

You can export results as XML files:

# Make sure the directory exists and you can write to it.
mkdir -p ~/var/drupal/tests
ls -al ~/var/drupal/tests
# If you provide a relative path to --xml option, it is considered relative
# to Drupal root.
# If you want the output to be outside Drupal root, use an absolute path.
php scripts/ --php /usr/bin/php --xml ~/var/drupal/tests PredictableTests

Running tests with drush

Drush is the recommended way to go.

I don't know wether it is possible to execute a single test within a test group with It is easy with Drush.


Drush's help tells that we must use the --uri option, but we don't get an error if we don't... With PredictableUnitTest, it seems to work without the option, so I don't know why this option is required, but let's use it because we are told to...

# Learn usage
drush help test-run

# See available test classes
drush test-run

# Execute "PredictableTests" group of tests
drush test-run --uri= PredictableTests

# Execute only "PredictableUnitTest"
drush test-run --uri= PredictableTests

# Execute only "PredictableUnitTest" with XML output as files
# As with, value of --xml is relative to Drupal root or make
# sure to provide an absolute path.
# Notice that the --xml syntax uses a "=" with drush and a space with
mkdir -p ~/var/drupal/tests
drush test-run --uri= --xml=~/var/drupal/tests PredictableUnitTest

About simpletest's web interface

Of course, you can use the simpletest's web admin interface at /admin/config/development/testing, as suggested in the simpletest documentation.

I'm personally used to command line tools, which I think are better for administrative tasks like running tests. So I recommend using the command line.

Another reason to prefer command line tools is that they can be used for automation. In the case of tests, you'd like building a continuous integration service with Jenkins [3].

Note about module development

I haven't yet figured out where Drupal stores the information, but when you add or edit some test classes, Drupal does not discover the changes. My current workaround is to disable the enable the module. But I guess it could be done with some cache clean.

Further readings


Voir aussi
La roadmap Drupal 8 La roadmap Drupal 8 05/04/2017

Sorti fin 2015, le CMS Drupal 8 a basculé dans un nouveau cycle de versions tous les 6 mois. Cet ...

Retour d'expérience sur la réalisation d'un portail Drupal mêlant cartographie et Open Data Retour d'expérience sur la réalisation d'un portail Drupal mêlant cartographie et Open Data 15/02/2018

Utilisation de Drupal comme outil centralisateur de flux.

Varnish et Drupal : gérer un cache anonyme étendu Varnish et Drupal : gérer un cache anonyme étendu 14/03/2018

Le rôle d'un Reverse Proxy Cache Varnish dans une architecture Web (type Drupal).

Drupal 8 pour un site d'université Drupal 8 pour un site d'université 17/01/2018

Pourquoi Drupal 8 est un bon choix pour réaliser un site d'université.

Drupalcamp Lannion 2017 : le pouvoir de la communauté Drupalcamp Lannion 2017 : le pouvoir de la communauté 06/11/2017

Compte-rendu du Drupalcamp Lannion 2017, un événement qui a tenu toutes ses promesses.