chapabu/codeception-module-drupal

A module for Codeception that exposes the Drupal API to test suites.

Codeception Drupal Module

Branch	Build Status	Coverage
Master
Develop

This module aims to allow tests to use the Drupal API during testing. This allows for better functional testing of your Drupal sites., _(*1)

It also makes test driven development with Drupal significantly easier, as you can make assertions on items that you create through the UI., _(*2)

Installation

$ composer require chapabu/codeception-module-drupal --dev

Usage

In your *.suite.yml file, add Drupal to your enabled modules list., _(*3)

Example configuration

This will run tests under the assumption that your Drupal installation is in a drupal sub-directory., _(*4)

class_name: AcceptanceTester modules:
    enabled:
        \Codeception\Module\Drupal7\Drupal7:
            root: 'drupal'
            relative: yes

Options

root

Accepts: string Default: current working directory, _(*5)

This defines the Drupal root in relation to the codecept.yml file. If this isn't passed in it defaults to the current working directory., _(*6)

relative

Accepts: yes or no Default: no, _(*7)

This allows you to specify if the path to the drupal root is relative from the codeception.yml file. Accepts yes or no., _(*8)

About URL-based functional tests

The Codeception Documentation on Functional tests says:, _(*9)

Now that we’ve written some acceptance tests, functional tests are almost the same, with one major difference: Functional tests don’t require a web server., _(*10)

This - or at least the first part of this - is not true for functional tests for Drupal 7 (whether they be based on this module or anything else). A little further, the same documentation says:, _(*11)

If your application was not designed to run in long lived processes (e.g. if you use the exit operator or global variables), then functional tests are probably not for you., _(*12)

We respectfully disagree. The technical part of this is true for Drupal 7. It does call exit and uses global variables. It also calls the header() PHP function directly, in some situations (e.g. in drupal_goto()), which also prevents the test process to survive more than one request. All this means, though, is that in Drupal 7's case, functional tests are nothing like acceptance tests, because HTTP-request-based tests (e.g. $I->amOnPage()) are not going to fly. This is why you will not find a Connector class in this package as with other frameworks., _(*13)

However, we still have access to the API and database, which lets us do some pretty useful stuff that both unit tests and acceptance tests are unable to., _(*14)

Contributing

Coding standards

Please ensure all code follows PSR-2 standards where possible (with the exception of and Codeception methods that don't follow this already, such as _initialize), _(*15)

Tests do not need to follow PSR-2 exactly, but should follow the standards laid out by the current tests (i.e. test method naming doesn't conform to PSR-2, but is more useful in this context)., _(*16)

Tests

All contributions should come with relevant unit tests as per the rest of the suite. For examples, look under the tests directory, _(*17)

Running tests - Linux/OSX

To setup for testing, run $ composer testinit followed by $ vendor/bin/codecept run or simply $ codecept run if you have Codeception installed system wide., _(*18)

The testinit.sh script assumes you have Drush installed system-wide. This will install Drupal using the username of root and a blank password to a MySQL database. Feel free to edit this file should you need to, but please ensure it is not committed back., _(*19)

Running tests - Windows

If you want to contribute and are running Windows, you should just run the command contained in the testinit.sh script using the command line., _(*20)

License

The project is licensed under The MIT License (MIT)., _(*21)