Acceptance testing

Revision as of 02:09, 8 March 2013 by David Monllaó Olivé (talk | contribs) (Installation)

Jump to: navigation, search


This page describes how we describe Moodle's functionalities and how we automatically test all of them.

Behat is a behavioural driven development (BDD) tool written in PHP, it can parse a human-readable list of sentences (called steps) and execute actions in a browser using Selenium or other tools to simulate users interactions.

For technical info:

How it works

Behat parses and executes features files which describes Moodle's features (for example Post in a forum), each feature file is composed by many scenarios (for example Add a post to a discussion or Create a new discussion), and finally each scenario is composed by steps (for example  I press "Post to Forum" or I should see "My post title"). When the feature file is executed, every step internally is translated into an PHP method and is executed.

This features are executed nightly in the HQ servers with all the supported databases (MySQL, PostgreSQL, MSSQL and Oracle) and with different browsers (Firefox, Internet Explorer, Safari and Chrome) to avoid regressions and test new functionalities.


  • There is a closed list of steps to use in the features, a feature written with the basic (or low-level) steps looks like this:
 Feature: Login
   In order to login
   As a moodle user
   I need to be able to validate the username and password against moodle
   Scenario: Login as an existing user
     Given I am on "login/index.php"
     When I fill in "username" with "admin"
     And I fill in "password" with "moodle"
     And I press "loginbtn"
     Then I should see "Moodle 101: Course Name"
   Scenario: Login as an unexisting user
     Given I am on "login/index.php"
     When I fill in "username" with "admin"
     And I fill in "password" with "moodle"
     And I press "loginbtn"
     Then I should see "Moodle 101: Course Name"

Note that The 3 sentences below Feature: Login are only information about what we want to test.

These are simple scenarios, but most of Moodle's functionalities would require a huge list of this steps to test a scenario, imagine a Add a post to a discussion scenario; you need to login, create a course, create a user and enrol it in the course... Most of this steps is not what we intend to test in a Post in a forum feature, Moodle provides extra steps to quickly set up the context required to test a Moodle feature, for example:

 Feature: Post in a forum
   In order to add contents to a forum
   As a moodle user
   I need to be able to enter the contents and verify they are correctly shown
     Given a "basic" moodle site
     And the following "courses" exists
       | fullname | shortname |
       | Course 1 | C1        |
     And the following "users" exists
       | username | firstname | lastname | email        |
       | student1 | First     | Student  | |
     And the following "enrolments" exists
       | username | courseshortname | enrolmenttype |
       | student1 | C1              | manual        |
   Scenario: Create a forum
     Given I am logged as an "admin"
     And I go to "Course 1" course
     And I add a "forum" to section "1"
     And I fill the form with:
       | Forum name        | ForumTest1                     |
       | Forum description | Test description               |
       | Forum type        | Standard forum for general use |
       | Any other field   | Value                          |
     When I press "Save and display"
     Then I should see "Test1"
     And I should see "Add a new discussion topic"
   Scenario: Add a post to a discussion
     Given I run "Create a forum" scenario
     And I go to "Course 1" course
     And I follow "ForumTest1"
     When I press "Add a new discussion topic"
     And I fill the form with:
       | Subject    | test subject |
       | Message    | message body |
     And I press "Post to forum"
     Then I should see "test subject"

Note that:

  • Background is executed before each scenario execution
  • Each scenario is executed in an isolated testing environment, so what you set up in an scenario (like the ForumTest1 forum in the example above) is cleaned up after the scenario execution
  • The prefixes "Given", "When" and "Then" are only informative and they as used to define the context (Given), specify the action (When) and check the results (Then).
  • In this example the Background section is used to set up the environment to distinct it from the test steps, but it can also be set in the Scenaio sections

Quick start

This is a quick introduction to write a functional test (acceptance tests) using steps in a development/testing site, please DON'T USE THIS IN A PRODUCTION SITE.

To let you experience the pleasure of watching a feature file doing "your work" automatically in a real browser, this guide includes 2 optional steps to download Selenium and run it in another CLI.

  1. Open a command line interface
  2. cd /to/your/moodle/dirroot
  3. Edit config.php adding the following lines before the lib/setup.php include
    $CFG->behat_prefix = 'b_';

$CFG->behat_dataroot = '/path/to/your/behat/dataroot/directory'; $CFG->behat_switchcompletely = true;

  1. curl | php (In case you have problems read
  2. php admin/tool/behat/cli/init.php
  3. Download selenium-server-standalone-2.NN.N.jar from, under "Selenium server (formerly the Selenium RC Server)"
  4. Open another command line interface and run java -jar /path/to/your/selenium/server/selenium-server-standalone-2.NN.N.jar
  5. vendor/bin/behat --config /path/to/your/behat/dataroot/directory/behat/behat.yml
  6. You just run the current Moodle tests, now let's add your own test, add a blog entry for example
  7. Browse to your $CFG->wwwroot, this is an empty test site and it is reset before each test (called scenario)
  8. From this point follow the steps you would follow to add manually a blog entry (login credentials are admin/admin)
  9. When you are done go to 'Site administration' -> 'Development' -> 'Acceptance testing', you will find the list of "actions" that can be run automatically, you can filter them to find what do you need to do (more steps can be added if you need, more info in
  10. To 'add a blog entry' we need to:
    1. Log in the system as a valid user
    2. Expand 'My profile' node of the navigation block
    3. Expand the 'Blogs' node of the navigation block
    4. Follow he 'Add a new entry' link
    5. Fill the moodle form with values for 'Entry title' and 'Blog entry body'
    6. Press the 'Save changes' button
    7. Verify you see the values you entered in the form and verify you are not in the form page
  11. This translated to steps is:
    Given I log in as "admin"

And I expand "My profile" node And I expand "Blogs" node And I follow "Add a new entry" And I fill the moodle form with:

 | Entry title | I'm the name |
 | Blog entry body | I'm the description |

When I press "Save changes" Then I should see "Blog entries" And I should see "I'm the description" And I should not see "Required"

  1. We need to wrap this steps following the behaviour driven development guidelines (more info in

@blog Feature: Add a blog entry

 In order to let the world know about me
 As a moodle user
 I need to write blog entries
 Scenario: Add a blog entry with valid data
   Given I log in as "admin"
   And I expand "My profile" node
   And I expand "Blogs" node
   And I follow "Add a new entry"
   And I fill the moodle form with:
     | Entry title | I'm the name |
     | Blog entry body | I'm the description |
   When I press "Save changes"
   Then I should see "View all of my entries"
   And I should see "I'm a description"
   And I should not see "Required"
  1. And save it into a file, in this case blog/tests/behat/add_entry.feature
  2. php admin/tool/behat/cli/util.php --enable (This will update the available tests and steps definitions)
  3. vendor/bin/behat --config /path/to/your/behat/dataroot/directory/behat/behat.yml --tags @blog
  4. Selenium will open a browser (firefox by default) and you will see how the steps you have been writting are executed

You can also try to expand non existing nodes or change the 'Then' assertions to get a beautiful failure.

For detailed steps and/or troubleshooting:



  • Edit config.php
    • Use $CFG->behat_dataroot to set the directory where behat test environment dataroot will be stored, something like $CFG->behat_dataroot = '/your/directory/path';. Ensure the directory can be created or have write permissions
    • Use $CFG->behat_prefix to set the database prefix of the behat test environment database tables, something like $CFG->behat_prefix = 'behat_';
  • Download composer
  • Install behat dependencies and enable the test environment
    • cd /your/moodle/dirroot
    • php admin/tool/behat/cli/init.php
  • (Optional) If you want to run tests that involves Javascript (most of them) you will also need Selenium

Running tests

  1. Start the PHP built-in web server
  2. (Optional) Start the Selenium server (in case you want to run tests that involves Javascript)
    • Open another command line interface and java -jar /path/to/your/selenium/server/selenium-server-standalone-2.NN.N.jar
  3. Run Behat
    • vendor/bin/behat --config /path/to/your/CFG_behat_dataroot/behat/behat.yml (For more options vendor/bin/behat --help or
    • In case you don't want to run Javascript tests use the Behat tags option to skip them, vendor/bin/behat --tags ~@javascript --config /path/to/your/CFG_behat_dataroot/behat/behat.yml
    • In case you are creating tests or adding steps definitions run php admin/tool/behat/cli/util.php --enable to update the list of tests
  4. (Optional) If you are adding new tests or steps definitions update the tests list:
    • php admin/tool/behat/cli/util.php --enable
  5. (Optional) Disable test environment (in case you want to use the PHP built-in web server for regular moodle environment)
    • php admin/tool/behat/cli/util.php --disable

Advanced usage

There are a few settings for advanced use of Behat and execution in continuous integration systems, by default all this options are disabled, use this settings only if you know what you are doing.

  • Different test server URL, by default the test web server only can be accessed in localhost. If for example your are interested in allowing accesses from your local network because your Jenkins server is there you can set $CFG->behat_wwwroot to
  • Behat configuration, Moodle writes a behat.yml config file with info about the available tests and steps definitions along with other Behat parameters, you can override the Behat parameters we set and add your new parameters, your parameters will be merged with the Moodle ones giving priority to your values in case of conflict. This is useful for an advanced use of Behat, with multiple profiles, output formats, integration with continuous servers...
  • Switch completely to test environment, DON'T USE THIS SETTING IN PRODUCTION SITES! all the site users would be using the test environment instead of the regular one with your courses and all your data and they wouldn't be able to login in your site; this setting should only be used in development/testing installations. It's purpose is to ease the integration with cloud-based continuous integration systems, another possible use is to allow acceptance testing in a development environment without PHP 5.4.

You can find more info and examples of how to use this settings in the config-dist.php file included in the Moodle codebase.

Writing features

All Moodle components and plugins (including 3rd party plugins) can specify their tests in .feature files using all the available steps.

Once you decided which functionality you want to specify as a feature you should:

  1. Select the most appropriate Moodle component to include your test and create a COMPONENTNAME/tests/behat/FEATURENAME.feature file
  2. Add a tag with the component name in Frankenstyle format ( on the first line
  3. Begin writing the user story of the feature, including in the 'As a ...' statement the main beneficiary of the feature:


 In order to ...
 As a ...
I need to ...
  1. From the beneficiary point of view, think of different scenarios to ensure the feature works as expected
  2. For each scenario you thought:
    1. Think of the initial context you need, for example 1 course with 2 students on it and an assignment, and which steps do you need to follow (interacting with the browser) to verify the scenario works as expected
    2. What you are testing requires Javascript? It doesn't include the steps to set up the initial context; think only on the feature you are testing (for example if you want to tests that you can view your profile you don't need Javascript to click on a link and assert against plain HTML, but if you want to test something related with the course's gradebook you might want to test it with Javascript)
    3. Check the steps list (more info in and set the initial context data (see for more info) and the steps to follow to verify all works as it should work. Remember to use Given, When and Then in a way that reflects what the scenario is testing
    4. Copy the list of steps to the .feature file with the Scenario header:
      Scenario: Short description of the scenario
 Given step 1
 And step 2
 And step 3
 When step 4
 And step 5
Then step 6
    1. If the steps you are using requires Javascript add the @javascript tag above the "Scenario:" headline

Scenario: Short description of the scenario

  1. Run the tests, when creating your new features/scenarios you can specify a 'wip' (work in progress) tag in both the line above the Scenario description and the test runner to execute only the new scenario instead of running the whole set of tests.

Available steps

Moodle provides a interface to list and filter the steps you can use when writing features. You can access it through the Administration block, following Site Administration -> Development -> Acceptance testing. It allows filtering by keyword, by the Moodle component or by the type of step:

  • Processes to set up the environment
  • Actions that provokes an event
  • Checkings to ensure the outcomes are the expected ones

Acceptance testing UI 2.5.png


  • To find as much issues as possible, use strings with problematic characters rather than easy strings like "Test activity description" which probably works as expected, you don't need to write these nasty strings, just copy $NASTYSTRING1 (where the "1" is an integer from 0 to 9) inside the step argument placeholder (something like I fill in "Username" with "$NASTYSTRING1") and Moodle will make the conversion to a really nasty string. Note that this nasty strings will be available once MDL-37858 is integrated.
  • Is better to tests the outcomes against the given data than against language strings, which are depending on the selected language.
  • The format of the .feature files is YAML which finds out the data hierarchy from the indentation of it's elements, so be sure that the elements are correctly nested and indentated using spaces

Providing values to steps

Most of the steps requires values, there are three methods to provide values to steps, the method depends on the step specification, you can know when a steps requires a value because you will see a upper case string between double quotes, something like I press "BUTTON_STRING" or it ends with a : . The three methods are:

  • A string/text; is the most common case, the texts are wrapped between double quotes (" character) you have to replace the info about the expected value for your value; for example something like I press "BUTTON_STRING" should become I press "Save and return to course". If you want to add a string which contains a " character, you can escape it with \", for example I fill the "Name" field with "Alan alias \"the legend\"". You can identify this steps because they ends with _STRING
  • A number; some steps requires numbers as values, to be more specific an undetermined number of digits from 0 to 9 (Natural numbers + 0) you can identify them because the expected value info string ends with _NUMBER
  • A table; is a relation between values, the most common use of it is to fill forms. The steps which requires tables are easily identifiable because they finish with : The steps description gives info about what the table columns must contain, for example Fills a moodle form with field/value data
  • A selector; there are steps that can be used with different kinds of elements, for example I click on "User Name" "link" or I click on "User Name" "button" this is a closed list of elements, in the 'Acceptance testing' interface you can see a dropdown menu to select one of these options:
    • field - for searching a field by its id, name, value or label
    • fieldset - for searching a fieldset by it's id or legend
    • link - for searching a link by its href, id, title, img alt or value
    • button - for searching a button by its name, id, value, img alt or title
    • link_or_button - for searching for both, links and buttons
    • select - for searching a select field by its id, name or label
    • checkbox - for searching a checkbox by its id, name, or label
    • radio - for searching a radio button by its id, name, or label
    • file - for searching a file input by its id, name, or label
    • optgroup - for searching optgroup by its label
    • option - for searching an option by its content
    • table - for searching a table by its id or caption
    • css_element - for searching an element by its CSS selector
    • xpath_element - for searching an element by its XPath


As seen in [examples] Moodle provides a way to quickly set up the contextual data (courses, users, enrolments...) that you need to properly test scenarios, this can be done using one of the site templates (TODO) or creating entities in the background section (common for all the steps) or in the "Given" part of your scenario. Note that this steps can only be used to set up the contextual data required to test the feature but they don't test what they are doing; for example, the "Given the following user exists" is not testing that Moodle is able to create a user, but to test that a user can add a blog entry you might want to use this step. For further info, acceptance tests are supposed to be black-boxed tests (the tester don't know about the internals of the application) and this steps are using internal Moodle data generators instead of running all the steps required to create a user or create a course, which speeds up the test execution. There are other features to test that all this elements can be properly created.

Available elements

Most of the available elements can only be created in relation to other elements, to hide the complexity of the Moodle internals (references by contexts, ids...) the references can also be done using more human-friendly mappings.

The examples below shows how to add elements referencing other elements, there are required fields to reference the elements, other attributes will be filled with random data if they are not specified.

  • Course categories
    • The required field is idnumber
    • References between parent/children by it's idnumber with the "parent" field
 Given the following "categories" exists:
   | name       | parent   | idnumber |
   | Category 1 | 0        | CAT1     |
   | Category 2 | CAT1     | CAT2     |
  • Courses
    • The required field is shortname
    • Uses the category idnumber as category reference
 Given the following "courses" exists:
   | fullname | shortname | category | format | 
   | Course 1 | COURSE1   | CAT1     | topics |
   | Course 2 | COURSE2   | CAT2     |        |
  • Groups
    • The required fields are course and idnumber
    • Uses the course shortname as course reference
 Given the following "groups" exists:
   | name    | description | course  | idnumber |
   | Group 1 | Anything    | COURSE1 | GROUP1   |
  • Groupings
    • The required fields are course and idnumber
    • Uses the course shortname as course reference
 Given the following "groupings" exists:
   | name       | course  | idnumber  |
   | Grouping 1 | COURSE1 | GROUPING1 |
   | Grouping 2 | COURSE1 | GROUPING2 |
  • Users
    • The required field is username (if password is not set username value will be used as password too)
 Given the following "users" exists:
   | username | password | email       | firstname | lastname |
   | testuser | testuser | | Test      | User     |
  • Course enrolments
    • The required fields are user, course and role
    • Uses the course shortname as course reference
    • Uses the user username as user reference
    • Uses the role shortname as role reference
    • Uses the enrolment name as enrol reference
 Given the following "course enrolments" exists:
   | user     | course  | role    | enrol  |
   | testuser | COURSE1 | student | manual |
  • Group members
    • The required fields are user and group
    • Uses the group idnumber as group reference
    • Uses the user username as user reference
 Given the following "group members" exists:
   | user     | group  |
   | testuser | GROUP1 |
  • Grouping groups
    • The required fields are grouping and group
    • Uses the group idnumber as group reference
    • Uses the grouping idnumber as grouping reference
 Given the following "grouping groups" exists:
   | grouping  | group  |

Adding steps definitions

Each Moodle component and plugin (including 3rd party plugins) can add new steps definitions. If you are writing tests and you notice that you are repeating the same group of steps you might want to create a new step definition that allows you to substitute the group of steps for one single step, something like I add a forum post with "blablabla" as description for example; also you can create whole new steps using the APIs provided by Behat and Mink if what you need to do is not covered by any of the available steps.

Check list

New steps should be/have:

  • Implemented as public methods of a PHP class whose name must begin with 'behat_' prefix and with '.php extension
  • Using the class name as filename (adding the '.php' extension) and extending MOODLEDIRROOT/lib/behat/behat_base.php (or MOODLEDIRROOT/lib/behat/behat_files.php if it's a repository or is files-related)
  • With a descriptive class name, for example the component name (it will be used when filtering steps definitions)
  • Stored in COMPONENTNAME/tests/behat/ directory or lib/tests/behat/ if is not part of any other component
  • Describe it's purpose in a single line inside the method doc comment, the size of the comment is not a problem
  • Describe the regular expression with the most appropriate tag inside the method doc comment:
    • @Given - A step to set up the initial context (for example the following "courses" exists)
    • @When - An action that provokes an event (for example I press the button "buttonname")
    • @Then - Checkings to ensure the outcomes are the expected (for example I should see "whatever")
  • Depending on the inputs your definition expects you must use a different regular expression:
    • If you expect a number: "(?P<info_about_what_you_expect_number>\d+)" (note that the regular expression is quoted between ")
    • If you expect a string or a text: "(?P<info_about_what_you_expect_string>(?:[^"]|\\")*)" Don't use text_selector_string and selector_string as info strings, they are reserved to selector types (note that the regular expression is quoted between ")
    • If you expect a table with key/value pairs (for example to fill a form): Finish your regular expression with : and provide info in the description about the contents of the table
    • If you expect a selector type: "(?P<selector_string>[^"]*)" or "(?P<text_selector_string>[^"]*)" depending on whether you want to use any selector or you want a text-based selector (more info about selectors in
  • To make test writer's life better is good to include explicative info in the subexpressions of the regular expression about what the test writer is supposed to put in there (for example I expand "(?P<nodetext>(?:[^"]|\\")*)" node)
  • Is recommended to use the static part of the regular expression as the name of the method, using underscores instead of spaces (see current steps definitions)


You can use this example below or any of the existing steps definitions as a template.

  • auth/tests/behat/behat_auth.php
 class behat_auth extends behat_base {
      * Logs in the user. There should exist a user with the same value as username and password
      * @Given /^I log in as "(?P<username_string>(?:[^"]|\\")*)"$/
     public function i_log_in_as($username) {
         return array(new Given('I am on homepage'),
             new Given('I follow "Login"'),
             new Given('I fill in "Username" with "'.$username.'"'),
             new Given('I fill in "Password" with "'.$username.'"'),
             new Given('I press "Login"'),
             new Given('I should see "You are logged in as"'));


If you are creating a completely new step definition there are also a few things to consider:

  • The definition code will be executed by Behat, not by Moodle, you have to keep this in mind for example when throwing exceptions, Behat exceptions will give more info to the user about where is the problem
    • You can find these exceptions in vendor/behat/mink/src/Behat/Mink/Exception/*
  • Selenium is fast, sometimes it tries to interact with DOM elements or tries to execute actions that requires JS that are not loaded or ready to used; this is why, sometimes and randomly, you can see an "element not found" failure
    • The quickest way to solve this problem is using behat_base::find*() methods (where the * corresponds to or to a named selector, which only requires the locator as argument. This methods will wait for the requested element to be ready or return an exception if the element is not found after the timeout value expires, you can also force the timeout value, which defaults to 6 seconds. An example of a named selector use is $button = $this->find_button("Save changes"); if you are not sure about the element being available you always can wrap the find*() call in a try & catch.
    • For advanced usages, the spin method is defined in lib/behat/behat_base::spin, consider that all the contents of the closures passed to spin() can be executed more than once, so don't use irreversible actions that can invalidate the tests results (for example use find() methods but don't use click() methods)
    • Note that this methods will not be available until will be integrated

If you create new steps definitions or tests you must run php admin/tool/behat/cli/util.php --enable to update the Behat config file before running vendor/bin/behat