C H A P T E R 2 5

■ ■ ■

Testing

One of the great new features incorporated into Drupal 7 core is the testing framework. You now have an integrated testing tool in core that allows you to define and automate testing of your Drupal site. The testing framework in Drupal 7 makes it possible to automatically run hundreds if not thousands of tests, making it easy to go to bed at night knowing that the changes you made to your site didn’t break your site.

In this chapter, I’ll show you how to enable the testing framework and define, execute, monitor, and review test cases.

Setting Up the Test Environment

The first step in setting up the test environment is enabling the Testing module in Drupal 7 core. Navigate to the Modules page, and scroll down until you find the Testing module. Check the box next to the module, and click the “Save configuration” button. The testing tools are now at your disposal and ready to be used.

Before we look at creating our own set of test cases, let’s look at the test cases that ship with Drupal 7. One of the key reasons Drupal 7 has been one of the most stable versions of Drupal ever released is the use of the testing framework to ensure that the entirety of Drupal core works as it should. Testing Drupal core the old way would have taken months and would have required a code freeze many months before launch, to provide enough time to thoroughly test the changes and enhancements to core. By using the testing framework, the development team was able to define a set of test cases that would definitively prove that Drupal core does what it’s supposed to do, and that it does it repeatedly after changes are made to the code that makes up Drupal core.

Let’s take a look at the test cases that ship with Drupal 7 core by navigating to Configuration -> Testing. On this page (see Figure 25-1), you’ll see a long list of what looks like Drupal 7 core modules, and in fact it is the list of Drupal 7 core modules and subsystems, e.g., AJAX or the Batch API. One of the tasks of the Drupal 7 core development team was to define a set of tests for each core module that could be executed to prove that each module produces the expected results.

545

CHAPTER 25 ■ TESTING

Figure 25-1. The off-the-shelf tests that are packaged with Drupal 7 core

Let’s run the tests associated with the Blog module as an example of how simple it is to execute a suite of tests in Drupal 7. Simply check the box next to the Blog module, scroll to the bottom of the page, and click the “Run tests” button. As soon as you click the button, Drupal does several things behind the scenes to prepare for the test, as shown in Figure 25-2. First it creates a complete Drupal installation. This approach creates a new environment every time you run a suite of tests, ensuring that the starting point for a test is identical every time the test is executed. The test framework then uses PHP cURL to walk through the predefined series of tests, just like you were sitting down at a browser and running the tests yourself, and it records and displays the results of your tests. It’s important to note that the testing framework starts with a clean Drupal install every time it executes a series of tests and cleans up the files and tables used to execute a test when the test is complete. In the setup process, you must define which modules need to be installed and enabled, what user accounts must be created, what content types need to be present, and in fact most of the steps that you would have gone through to set up your site will need to be performed by scripting the test setup process, which I will cover in detail shortly. The benefit of this approach is that you start with a clean slate every time, ensuring that the same tests consistently produce the same results because they’re starting with the same baseline environment and not one that continues to change over time due to other testing activities, and you don’t contaminate your development or testing site with test data.

546

CHAPTER 25 ■ TESTING

Figure 25-2. The testing process in Drupal 7

At the conclusion of the test cycle, Drupal tears down the test environment and displays a summary page that reports how many tests were executed, how many test conditions failed, how many exceptions were reported, and the number of debug messages that were captured during the testing process. Figure 25-3 shows the results of running the Blog tests.

Figure 25-3. Results from running the Blog tests

547

CHAPTER 25 ■ TESTING

As you can see from the test results, 241 tests were executed in 1 minute and 44 seconds, and all of the tests passed. Attempting to do that manually without test automation would have taken hours with the potential for human error while executing the tests.

To see the detailed results of the tests, I’ll click the Blog Functionality link, exposing the list of tests that were executed and the detailed results of each test that were logged during test execution.

Figure 25-4. The list of test conditions that were executed and their status

Scrolling down the list of test conditions, you’ll likely find links to Verbose messages (see Figure 25-5). These messages typically include screen captures of the results of a test case, providing physical proof that the test script did what it was supposed to do, which is useful when you’re debugging tests.

548

CHAPTER 25 ■ TESTING

Figure 25-5. Test results with Verbose messages provide additional details like screenshots.

Clicking the Verbose message on line 39 displays a saved/static version of the XHTML output that was taken at the moment this test condition was executed (see figure 25-6), providing definitive proof that the site met the expected results as defined in the test condition.

Figure 25-6. A screenshot taken by the test script showing actual results

549