Testing Area/Behat Testing/Characteristics of a good test
From Mahara Wiki
< Testing Area | Behat Testing(Redirected from Testing/Behat Testing/Characteristics of a good test)
How to write a good test
This page will break down the different components that make up a Behat test and teach you step by step.
Template
These are quick copy and paste templates for you to use. Copy and paste into your text editor and remember to save in the feature directory and as a .feature file
Single scenario on a page | Multiple scenarios on one page. |
---|---|
@javascript @core Feature: In order to As an So I can Scenario: Given And When And Then
|
@javascript @core Feature: In order to As an So I can Background: Given And And And @core_ Scenario: Given And When And Then @core_ Scenario: Given And When And Then |
Tags
- The tags are how we run the tests, to run a group of tests on Jenkins at once we identify the ones to run by the tag.
- Always attach an @javascript tag to the top of the page. This will run all the scenarios on the page, don't tag each scenario with @javascript. One at the top is enough.
- If it's testing a core feature tag it @core, this will be all tests except 3rd party plugins.
- Tags at the top of the page, run all the scenarios on the page.
- Tags on the scenarios just run those scenarios.
- If there are multiple scenarios on the page and they are testing multiple parts of a feature, tag the top of the scenario appropriately.
Feature
- Good features clearly explain what you are trying to do. If you are using a bug from Launchpad to write the test, remember to include the number in the feature file as a comment.
Feature: Creating a group In order to create a group As a student So I can become a part of the group and share my work
- The first line of the feature is the title of what you are testing
- In order to <do something specific>
- As a <who you are logging in as> (remember if you are logging in as a student you first need to have the student account created, use the background for this)
- So I can <tell us what the end game is here. So you can do what?>
Background
- Backgrounds come after the feature and before the first scenario and cannot be placed on any other part of the test.
- Backgrounds are good for efficiency and save you from having to write the same steps over and over again. Use a background to log in as an admin, create users, create groups and all the prerequisites you need to test as that user.
- Backgrounds are used when you have multiple scenarios on the page that use the same prerequisites. For example, both scenarios need 4 users to be a part of group so they can share pages to the group. The background would be used to create the four users and then group. The scenario steps would then log in and share the a page to the group and then verify that the page was shared.
- Any scenario that you put on the page will follow the same pathway as the background before initiating the scenario, so make sure all scenarios actually need that background.
For an example click the link in the Behat docs above.
Scenarios
- Scenarios are just describing what you are doing to test the feature. For example, "Creating a Portfolio page" or "Checking only one search box is visible on the homepage".
- You can have multiple scenarios on the page, they should be on the same page if they are relative to each other.
- Scenarios should have the bug numbers on it, if the test is being written from a bug in Launchpad.
For example:
Scenario: Checking only one search box is visible on the homepage (Bug 12341234)
Steps
- Steps have a special syntax for Mahara found here
- Every link/button/check box or text box you click in has to be written as a step so the Behat test can click it automatically and run.
Data table
- Data tables are a quick way to execute a lot of steps. When you are filling out of a form there are lots of text boxes to click inside and fill in. Use data tables to fill them in. For example:
And I fill in the following: | Page title | Perfect page | | Page description | This is where you describe the page |
- Also use data tables for adding more than one user (you can use this in background also), for example:
Given the following "users" exist: | username | password | email | firstname | lastname | institution | authname | role | | userA | Password1 | [email protected] | Pete | Mc | mahara | internal | member |
Given the following "groups" exist: | name | owner | description | grouptype | open | invitefriends | editroles | submittableto | allowarchives | members | staff | | group 01 | userA | This is group 01 | standard | ON | ON | all | ON | ON | userB, userC | userD |
Comments
- Commenting on your test makes it human readable.
- It allows the person reading it to know what page you are on.
- Use a space after the #
- Use the commenting as milestone markers. For example:
And I follow "Portfolio" # Creating a page And I press "Create page" # Filling in the page title When I fill in the follow: | Page title | Awesome page | | Page description | Describing the page | And I press "Save" # Saving the configuration settings of the page And I press "Done"