Jan 13 2016
Jan 13

Short history of Tests in Drupal

In Drupal 7 it was fairly straight forward what kind of a test you should write, especially for core. It would basically be a simpletest. If you wrote in contrib, you might write a few Behat or PHPUnit tests for your module, but you would either run these tests locally of on some remote testing server such as Jenkins or Travis.

While this was quite good for doing webtests along the lines of ‘create user’, ‘log in’, ‘go to page x’, ‘click on button y’, it was also pretty slow. Every patch on the issue queue could be delayed as much as 3 hours while all the tests ran and during sprint weeks we end up with huge queues of patches waiting to be tested.

Drupal 8 has really stepped up its game. In 2013 it separated our testing into two categories. one for web tests that require a complete or partial Drupal environment - Simpletests, and another for everything else - PHPUnit :) PHPUnit Change Notice

It didn’t take long for there to be several different subclasses for PHPUnit tests in Drupal:
Unit Tests
Kernel Tests
Functional Tests

What now?

So now the question is, “Which test should I be writing”. Here is a quick explanation of the different Test Base classes.

Drupal Test Structure

- TestCase (PHPUnit_Framework_TestCase)
  - \Drupal\KernelTests\KernelTestBase
  - \Drupal\simpletest\BrowserTestBase
  - \Drupal\Tests\UnitTestCase
- \Drupal\simpletest\TestBase
  - \Drupal\simpletest\KernelTestBase
  - \Drupal\simpletest\WebTestBase
    - \Drupal\simpletest\InstallerTestBase

TestCase and TestBase should never be extended directly. They are just structure that the remaining tests extend.

UnitTestCase is what you want if you don’t care about bootstrapping Drupal. All you want to do is test Class methods and make sure that they behave expectedly. Eg. If your method required the first argument to be a string and you pass it an array you get an exception, etc.

Next up we have KernelTestBase, WebTestBase and BrowserTestBase. These all do something towards setting up a Drupal Environment and allowing you to test your code in the wild. KernelTestBase is the simplest as it bootstraps Drupal and sets up a Database, etc. but it doesn’t explicitly install any modules, and so is similar to the environment in the early installer. Any modules that you require are loaded in setUp() and you can perform schema installation as required.

Notice: there are two KernelTestBase classes. \Drupal\simpletest\KernelTestBase has been deprecated for \Drupal\KernelTests\KernelTestBase as part of Drupals continuing battle to modernise its testing and has moved from simpletest to PHPUnit. KernelTestBase Change Notice

Then we get to WebTestBase and BrowserTestBase. They do basically the same thing, as they allow a full installation of Drupal and modules and are webtests so you test the UI through a browser. The general rule of thumb is use WebTestBase. BrowserTestBase is the newest move to modernize testing as it is an attempt to move Browser Testing from simpletest to PHPUnit and Mink BrowserTestBase Change Notice. So if you fancy it, you can give the new framework a go, but it is still work in progress and not going to be used extensively in core until 8.1.x.

And finally there is InstallerTestBase which is useful testing the installation of Drupal based on changes in configuration.

Sep 11 2012
Sep 11

Since Drupal 6 and Drupal 7 a lot of popular modules like ctools, rules and views (and probably many more) had some kind of way to extend it's functionality by writing so called plugins. The idea was to swap out certain behavior of your system by another plugin of the same type.
For example you can replace the output/style of a view to a fancy slideshow by choosing another style in the user interface.

There were multiple "standards" how to create such systems,
so for different modules you always had to learn a new way,
made different mistakes and basically wasted a lot of time.
Therefore in d8 one goal was to unify them and make it
much easier to use.

A plugin in d8 will be always some kind of php-class which are part of a namespace, which correlates with the folder/filename. This sounds maybe complicated but let's have a look at an example.

Assume you want to add a new style plugin to views you would in d8

  • Create a file called Example.php in the folder your_module/lib/Drupal/your_module/Plugin/views/style
  • At the top of the file you define the namespace:

    namespace Drupal\your_module\Plugin\views\style;

To be able to tell drupal of your plugin, you use Annotations,
which are basically comments in your php code.

They contain metainformation attached to
the plugin directly. You can compare this basically with the info hooks in d7:

// Add the below used views baseclass.
use Drupal\views\Plugin\views\style\StylePluginBase;
// These two lines are required to scan the code for the plugin.
use Drupal\Core\Annotation\Plugin;
use Drupal\Core\Annotation\Translation;

// The actual annotation starts:
 * @Plugin(
 *   id = "style_example",
 *   title = @Translation("Just an example style plugin to explain the plugin system"),
 *   additional_info = "Some random information"
 * )
class Example extends StylePluginBase {

That's all you need to start writing your plugin. Just have a look at the attachment for everything that is needed.

Now we learned how to write a views plugin, but you will be able to apply this to nearly everything in drupal8 for example a block plugin (the d8 way to write custom blocks).
You add the file with a class of the right namespace and add the annotations, probably clear your caches and be happy ... see screenshot.

I neglegted some internal things of the plugin system which either will let you explode your brain or feel really excited.
A long documentation of the new system can be found under: http://drupal.org/node/1637614

Thanks for the scotch and wscci initiative for the implementation of such a flexible system.

AnhangGrösse 2.88 KB

About Drupal Sun

Drupal Sun is an Evolving Web project. It allows you to:

  • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
  • Facet based on tags, author, or feed
  • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
  • View the entire article text inline, or in the context of the site where it was created

See the blog post at Evolving Web

Evolving Web