Writing Tests

At Discovery Garden, we're implementing Continuous Integration using Jenkins, an open source CI solution. This means that every time code is committed to certain GitHub repositories, automated tasks will be executed against the codebase. Included in these tasks will be a battery of tests executed in multiple environments. Once code passes the entirety of the test suite in all environments, it can be deployed into production. If any test fails, the developer will be notified so that the issue can be addressed immediately. Adopting this practice will lower the risk of development and maintenance, while increasing overall confidence in the product.

All tests will be written using Drupal's Simpletest module, which has been integrated into the Drupal Core as of version 7. The Simpletest module provides some conveniences for writing tests, and can be used to develop unit tests for verifying basic functionality outside of a fully bootstrapped Drupal context. The Simpletest module also has the ability run what it calls "web" tests, providing a fully bootstrapped Drupal context for each test function.

Simpletest Installation

Drupal 6

Drupal 7

Anatomy of a test file

All test files end in the extension .test, and should reside alongside the code whose functionality is being tested. For example, if you have a module with a basic file structure such as

• my_module
  • my_module.module
  • my_module.info
  • my_module.install

In Drupal 6, all you have to do is create a my_module.test file and place it in the my_module directory. If you're in Drupal 7, and additional step of pushing the file name onto the files array in your .info file. files[] = my_module.test

Unit Tests

Unit tests do not require a running instance of Drupal. Because of this, they are much faster than their web test counterparts and are preferred over web tests whenever possible. In order to provide

Writing Web Tests

While developing new features or revisiting old code, it is the task of the developer to provide tests demonstrating that the basic functionality of the code is working as expected. This can be a daunting task, especially when facing a large and established code base. Although the exercise of creating tests ultimately results in a judgement call of some sort, here are a few basic guidelines to help get you started.

Test the interface, not the implementation.

This approach to testing is known as Black Box Testing. If you are testing a particular class or collection of functions, you should ensure the output received from all public functions is as expected given the input you have provided.

Sometimes you want to fail.

At times, code should be expected to fail gracefully when confronted with incomplete or missing parameters. In situations like this, we often want to let it fail and negate that output in the assert statement.