This article is part of the Google Summer of Code blog series.

It's been more than 2 weeks since coding summer with Google was started. During the first week, I was working on building a prototype of Mailhandler module for Drupal 8.

In order to finish the prototype and merge the feature branch, I had to provide automated test coverage.

Drupal provides two types of automated tests:

• Functional tests test the functionality of Drupal systems at a higher level and consist of:
  • Web tests - executed via Drupal's specific simpletest framework and used to test the web output of Drupal
  • Kernel tests - do not require Drupal web output. As of Drupal 8.2.x, PHPUnit is used to run Kernel tests instead of Simpletest
• Unit tests - based on PHPUnit testing framework, test the functionality of classes at a low level

To tests our Mailhandler prototype, I decided to write Kernel and Web tests.

Writing Web tests

Each web test has to be in the specific namespace (in my case that is namespace Drupal\mailhandler_d8\Tests) and needs to extend Drupal\simpletest\WebTestBase class to be found by simpletest module.

The web test needs to have a static array of modules that are going to be enabled on a test run. A great thing about web tests is they resolve module dependencies recursively. Thus, for a basic module test coverage, we just need to add a module dependency.

Beside the modules array, the web test needs to have setUp method (executes only once) and at least one test method. Our test method - testMailhandlerNodeUi asserts that default handler configuration is correctly displayed and updated. Also, it tests the edge case when there are no content types available. The full web test for MailhandlerNode plugin can be found on Github.

Writing Kernel tests

The namespace and base class are a bit different for functional Kernel tests. We have to put the test into Drupal\Tests\mailhandler_d8\Kernel and extend Drupal\KernelTests\KernelTestBase class. As opposed to Web tests, static array of enabled modules must contain all the modules that are going to be used in the test. Also, setUp method needs to contain entity schemas and default configuration of relevant entities/modules. Sometimes, this can be time-consuming. The kernel test is available on Github as well.

Running tests

To run the tests we will need to have simpletest module enabled. The module can be enabled via user interface or using Drush ("command line shell and Unix scripting interface for Drupal") by typing drush en simpletest -y in terminal. If you are not using Drush already, I highly recommend you to give it a try.

Like many things in Drupal, we can run tests through user interface or command line using the following command:

php /drupal_root/core/scripts/run-tests.sh --browser --url http://drupal.domain --module mailhandler_d8

--browser tells simpletest to open test results in a browser. It can be useful in case you want to know more about your test fails.
--url specifies the base URL of the Drupal root directory.
By adding --module we set the module we want to run tests from. In case we want to test a specific test or even a test method we could use --class parameter.
How to run tests through command line is explained on the official documentation page.

Passing tests on Travis CI allowed us to merge the feature branch into 8.x-1.x (master) branch. By doing the merge, child and meta issue updates, sprint 2 (week 2) was successfully completed. 

For the third week of GSoC the plan is to extend the module with authentication methods. I will update you how we can authenticate a mail sender using "from" mail header field. Also, we are going to provide better security by adding support for digitally signed emails. Until next time!