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
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.
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)