Actions

Testing Area/Behat Testing/Characteristics of a good test: Difference between revisions

From Mahara Wiki

< Testing Area‎ | Behat Testing
No edit summary
 
(25 intermediate revisions by 3 users not shown)
Line 1: Line 1:
<h1>How to write a good test</h1>
= 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.


<h2>Template</h2>
== Template ==


Copy and paste into your text editor and remember to save in the right directory and as a .feature file
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
{| class="wikitable"
|-
! '''Single''' scenario on a page  
! '''Multiple''' scenarios on one page.
|-
|
<pre>
<pre>
  @javascript @core
  @javascript @core
Line 19: Line 25:
   And
   And
   Then  
   Then  
</pre>




</pre>
'''Multiple''' scenarios on one page.


||
<pre>
<pre>
  @javascript @core  
  @javascript @core  
Line 52: Line 74:
   And
   And
   Then
   Then
</pre>
|}


== Tags ==
[http://behat.readthedocs.org/en/v2.5/guides/6.cli.html#gherkin-filters Behat docs on tags]


</pre>
* 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.  
<h2>Tags</h2>
 
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 @javasript. 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.
* 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 at the top of the page, run all the scenarios on the page.
* Tags on the scenarios just run those scenarios.
* Tags on the scenarios just run those scenarios.
* If there are multiple scenarios on the page and they are testing are testing multiple parts of a feature, tag the top of the scenario appropriately.
* If there are multiple scenarios on the page and they are testing multiple parts of a feature, tag the top of the scenario appropriately.
* A


== Feature ==
[http://docs.behat.org/en/v2.5/guides/1.gherkin.html#features Behat docs on Features]


 
*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.  
<h2>Feature</h2>
Good features clearly explain what you are trying to do. If you are using a bug from Launchpad to write the test, use the title of the bug in the title of the feature.  


  Feature: Creating a group
  Feature: Creating a group
Line 79: Line 99:


* The first line of the feature is the title of what you are testing
* The first line of the feature is the title of what you are testing
* In order to do something specific
* In order to <do something specific>
* As an, who you are logging in as (remember if you are logggin in as a student you first need to have the student account created, use the background for this)
* 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?  
* So I can <tell us what the end game is here. So you can do what?>
 
== Background ==
 
[http://docs.behat.org/en/v2.5/guides/1.gherkin.html#backgrounds Behat docs on backgrounds]
 
* 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 ==
[http://docs.behat.org/en/v2.5/guides/1.gherkin.html#scenario-outlines Behat docs for 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)


<h2>Background</h2>
== Steps ==
[http://docs.behat.org/en/v2.5/guides/1.gherkin.html#steps Behat docs for Steps]


* Steps have a special syntax for Mahara found [https://wiki.mahara.org/index.php/Testing/Behat_Testing/Steps 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.


<h2>Scenario</h2>
=== Data table ===
[http://docs.behat.org/en/v2.5/guides/1.gherkin.html#tables Behat docs for data tables]


* 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 |


<h2>Steps</h2>
* 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 |




<h2>Comments</h2>
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"


[[Category:Behat]]
[[Category:Behat]]

Latest revision as of 16:22, 7 August 2020

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

Behat docs on 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

Behat docs on Features

  • 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

Behat docs on backgrounds

  • 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

Behat docs for 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

Behat docs for 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

Behat docs for data tables

  • 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"
Retrieved from ‘https://wiki.mahara.org/index.php?title=Testing_Area/Behat_Testing/Characteristics_of_a_good_test&oldid=11725’