To start, we need to add a Behat feature. Create a file under the features/ directory (e.g. features/devel.feature) that contains the feature specification. For example, here’s the beginning of a “Developer tools” feature:
Feature: Developer tools
In order to accelerate development of Ægir
as a Developer,
I want to be able to securely and easily enable and disable developer tools
@security @wip
Scenario: Ensure developer tools are disabled by default
Given I run "drush @default pm-list --status=enabled --type=module --core --format=list"
Then I should not get:
"""
features_ui
views_ui
devel
"""
Note that the latest scenario we’re about to build is tagged with “@wip”. This represents a ‘work-in-progress’, and won’t be run during our automated CI tests.
$ make drupal-tests-wip
Downloading the 1.0.0-beta1 release of Composer.
[...]
Generating project-specific Behat config.
Feature: Developer tools
In order to accelerate development of Ægir
as a Developer,
I want to be able to securely and easily enable and disable developer tools
@security
Scenario: Ensure developer tools are disabled by default # features/devel.feature:7
Given I run "drush @default pm-list --status=enabled --type=module --core --format=list" # FeatureContext::iRun()
Then I should not get: # FeatureContext::iShouldNotGet()
"""
features_ui
views_ui
devel
"""
1 scenario (1 passed)
2 steps (2 passed)
0m3.91s (22.22Mb)
If this is the first time that you’re running the test suite in this project, then the above command will install Behat for you.
As we can see, this test passed (as expected). This is only because it’s testing the default state. But now we need to re-run that test, to ensure that it can fail. If we don’t confirm that the test fails before implementing the feature it’s intended to test, then we have a false negative. That is, the test isn’t really ensuring that the desired functionality actually works. Thus it wouldn’t be helpful in flagging regressions later on either.
In this case, we need to simply enable one of the modules that we’re going to make a part of our feature, and re-run the tests:
$ drush -y @default en views_ui
The following extensions will be enabled: views_ui
Do you really want to continue? (y/n): y
views_ui was enabled successfully. [ok]
views_ui defines the following permissions: administer views
$ make drupal-tests CURRENT_TEST=features/devel.feature
Generating project-specific Behat config.
[...]
Given I run "drush @default pm-list --status=enabled --type=module --core --format=list" # FeatureContext::iRun()
Then I should not get: # FeatureContext::iShouldNotGet()
"""
features_ui
views_ui
devel
"""
'views_ui' was found in command output:
------
block
[...]
views
views_ui
--- Failed scenarios:
features/devel.feature:7
1 scenario (1 failed)
2 steps (1 passed, 1 failed)
0m1.83s (22.30Mb)
Note that, when we called make drupal-tests, we set the CURRENT_TEST variable to point to the file where our current tests reside. This is another way to limit the tests we’ll run on any given invocation.
Anyway, that failed, as expected, thus confirming that our test is valid. We can remove the “@wip” tag, since this feature will work as-is. Next let’s define what should happen when we enable our feature. Again, in features/devel.feature, we add our next scenario:
@wip
Scenario: Enable developer tools
Given I run "drush -y @default en aegir_devel"
Then I should get:
"""
aegir_devel was enabled successfully.
"""
And I run "drush @default pm-list --status=enabled --type=module --format=list"
Then I should get:
"""
aegir_devel
features_ui
views_ui
devel
"""
Running this test ought to fail with an error like this:
Scenario: Enable developer tools # features/devel.feature:21
Given I run "drush -y @default en aegir_devel" # FeatureContext::iRun()
aegir_devel was not found. [warning]
No release history was found for the requested project [error]
(aegir_devel).
The next step is to implement the feature on the dev Drupal site. The easiest way to accomplish this is to use Features to create a module, building out the necessary scaffolding for us. The Features module is already included in our makefile, and thus available on our dev site. It need only be enabled. We won’t go into detail on how to build Features, since that’s beyond the scope of this documentation.
Once the Feature has been exported, our tests ought to pass. If not, we’ve likely missed something, which should become pretty obvious from the output of our tests. Iterate on your feature until it passes the current scenario. Once it does, you should remove the “@wip” tag and commit the code. Remember to add a good commit message.
Upon pushing this code, our Continuous Integration (CI) system should kick off our test suite. Ensure that the new tests are being run (and passing, of course). After that, you’re ready to tackle the next scenario.