TestEngineering/Web/Automation/Gaia UI Testing

Summary

This is the home for all documentation related to the Gaia UI tests written and maintained by the Web QA Team.

Running the Tests

Running on Desktop B2G

Either add documentation for this here, or link to existing documentation, which I believe is currently in the Github repo.

Running on Device

Either add documentation for this here, or link to existing documentation, which I believe is currently in the Github repo.

Keeping Branches in Sync with Master

Currently, all development of Gaia UI tests is done on the master branch, with the exception of fixes that are needed specifically for a different branch. It is our goal to keep other branches of interest as closely synced with master as possible. When changes are committed to master, it is important to determine whether those changes should also be uplifted to other branches, and if so then the uplift must be completed.

Current Branches of Interest

• Master - this is the current development branch of Gaia and is priority #1 for failing tests. All new development (e.g., new tests) should be completed in the master branch and then, if necessary, uplifted to other branches of interest.
• v1.2 - this is the next shipping version of Gaia, and is priority #2 for failing tests. Changes should only be committed to v1.2 if they either:
  • land first in master and are deemed necessary for v1.2, or
  • contain fixes that are specific to v1.2

This means that the only current branches of interest are master and v1.2. For this reason the rest of this page will use v1.2 to mean any branch of interest.

After Changes Have Been Committed To Master

The following steps should be taken:

1. Determine whether the change should be uplifted to v1.2. There are a number of considerations for this including:
   1. If it is a new test:
      1. Are the features being tested available in v1.2? If yes, then it should be uplifted, otherwise do not uplift.
   2. If it is a fix to a failing test on master:
      1. Is it a locator or other change that causes the test to fail on master but not on v1.2? If yes, then do not uplift.
      2. Is it a test enhancement, such as an improved wait? If yes, then it should be uplifted.
   3. If, after considering the above, you are unsure as to whether the commit should be uplifted to v1.2, then flag it for uplifting and add a comment that you are not sure if it is needed or not. By flagging it for uplifting you are ensuring that someone will look at it and make that determination.
2. Flag the bug to indicate if it is to be uplifted or not, or complete the uplift yourself:
   1. If the commit should be uplifted (or you are unsure, as above), either:
      1. Flag it for uplifting by setting the status-b2g-v1.2 flag to 'affected', or
      2. Complete the uplift yourself. This is preferable to flagging it for someone else to complete. See the section below about Uplifting Commits.
      3. In either case, the bug should not be closed.
   2. If you determine that the commit does not need to be uplifted, flag it as such by setting the status-b2g-v1.2 flag to 'unaffected'. The bug can be closed.

Uplifting Commits

Uplifting means to take the changes in a commit made to master, and bring those same changes into the branch of interest. Here is a recommended workflow:

1. Make sure you are on the correct branch and that it is up to date:
   1. git checkout v1.2 && git pull upstream v1.2