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 you are still unsure as to whether the commit should be uplifted to v1.2, then flag it for further determination by setting the status-b2g-v1.2 flag to '?'.