Column

Writing tests for a project is a terrific way to learn about its underlying code. In the case of Drupal 8, nearly all the code is a complete overhaul from Drupal 7. For folks familiar with the inner workings of Drupal 7, writing PHPUnit tests for a given part of the codebase is a perfect way to understand what has changed.

As of June 2015, there are 566 active issues in the Drupal 8.0.x queue tagged with Needs tests. There’s lots of room for contribution for folks who can write a test. Since this column is dedicated to testing, let's look at the benefits of pushing Drupal 8 forward through test writing.

There are three different types of tests in Drupal 8:

• Unit tests (PHPUnit) are used to test that the individual classes function as expected in relative isolation.
• Integration tests (KernelTestBase) expand from this concept, but still only pull in code needed to test.
• Functional tests (WebTestBase and BrowserTestBase) bring everything together, perform a full site install, and then assert the expected behavior.

Note that since the functional tests perform a full site install, they are quite slow, and should only be used when integration or unit tests are insufficient.)

To get started, find an issue in the “Needs work” or “Needs review” state that already has a patch and is tagged “Needs tests.” If the issue already has tests, update the issue to remove that tag and move along, or review the issue, give feedback, and then move along.

When a patch that only contains the fix is found, the next step is to backward-engineer the bug. The test must fail without the patch – meaning it shows that this is a bug – and then, with the patch, the test must pass. This pattern makes it easy for overworked core committers to see that the problem has been demonstrated and fixed.

For folks writing their first test, the ideal issue will have clearly defined “steps to reproduce” in the issue summary. The test then is essentially an automated way of reproducing those.