This document provides an overview of how Moodle HQ tests Moodle functionality automatically. It describes using a human-friendly language to write testing scenarios, Selenium to simulate real user interactions, and Jenkins to run the tests automatically on multiple browser and OS combinations. The goal is to ensure new code changes don't break functionality and to expand coverage of Moodle's features.

1. Testing Moodle functionality
automatically
A quick overview of the process we follow
at Moodle HQ to test Moodle functionality
automatically.

2. Who I am
David Monllaó - Test engineer at Moodle HQ
Integration team

3. Points
From a behaviour description to a tested
functionalities report.
1. Human-friendly language
2. Real users simulation
3. Running automatically

4. Human-friendly language
Scenario: Add a blog entry with valid data
Given I log in as "admin"
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 "I'm a description"
And I should not see "Required"

5. Human-friendly language
When I press "Save changes"
• “Save changes” is a variable, we read the page contents
looking for a button labelled as “Save changes”.
Then I should see "I'm a description"
• “I'm a description” is a variable, we read the page
contents looking for the “I'm a description” text.

6. Real users simulation
We use an open source project named Selenium.
As the official Selenium documentation states:
“Selenium automates browsers. That's it”
Is a server application that receives commands
(click or type keyboard keys) that it executes in a
browser.

7. Real users simulation
From human-friendly sentences to Selenium
commands.
1. When I press "Save changes"
2. When I press $variable
3. Find <button value=”$variable”> identifier in the page
contents
4. Send a click/ID command to Selenium
5. Selenium executes the click in the “Save changes” button like
a real user does

8. Real users simulation

9. Running automatically
• Moodle codebase includes around 160 different scenarios
(90 features)
• We use Jenkins Continuous Integration server to:
o Run the features in a regular basis, ensuring new code changes don't break
any functionality
o Release new moodle versions knowing that X of Moodle's features works as
expected
o Run all those features in multiple combinations of Browsers and Operating
Systems
• We will continue adding new feature files to expand
Moodle's functionalities coverage.

10. Running automatically

11. Running automatically
Anyone can do it, all is included in Moodle's
codebase, can be useful to:
• Contribute new feature files describing Moodle's
functionalities
• Add feature files for the 3rd party plugins you develop
• Run the test suite to ensure your local code modifications
are not breaking any of Moodle's functionalities

12. More information
• Moodle Docs – Acceptance testing
o
http://docs.moodle.org/dev/Acceptance_testing
• Selenium
o
http://docs.seleniumhq.org/
• Jenkins Continuous Integration
o
http://jenkins-ci.org/
• Behat
o
http://behat.org

13. Any questions?
Thanks for your attention!
Moodle HQ (http://moodle.com)
David Monllaó (davidm@moodle.com)