“I did enjoy reading the article about e2e test on wordpress. I noted that e2e test are in a separate repo.
My question will be what is the workflow to make sure new changes does not break the e2e test on pull request ?
For example, if a developer work on some changes, then they need to change the e2e test first and make sure everything pass, however the environment on the pull request might not be stable, developer can overwrite each other changes”
Thanks for your question Liam.
We have reasons for and benefits in having the WordPress.com e2e tests in a separate repository:
- The e2e tests test the entire WordPress.com experience so these test things that happen in different repositories (for example our Calypso user interface or services/API) and having them in the user interface repository isn’t really representative of what the breadth of their scope;
- Making changes to the e2e tests are easier in a separate repository since we don’t have to deploy e2e PRs that don’t contain functional changes (we deploy every merge to our master branch immediately dozens of times per day)
The obvious downsides are:
- How do we make sure e2e tests know about incoming AB tests?
- How do we couple new changes to updates in the e2e test repository?
For incoming AB tests we make sure that our e2e tests know about the change by ensuring we create a matching PR in our e2e tests that override our AB tests during our test runs.
If someone updates the AB tests in Calypso they’re politely reminded to update the e2e tests:
For making sure e2e tests are up to date we automatically run two (of about 40 total) of the most critical e2e tests (in three browsers) when a PR is ready to be reviewed. These can fail and indicate a change is necessary to the e2e tests (or something is broken!)
There’s also a label we can add to any PR that runs the entire set of e2e tests against a PR running live and reports the result back to that PR:
If changes are required to the e2e tests someone can create an e2e PR with the exact same branch name which will be used to run against the feature changes before they are merged. This means PRs can be coupled and tested together but merged separately.
To answer the second part of your question I understand it to be about conflicting changes? One of our key philosophies for work is “merge early and merge often” so we make sure that PRs are short-lived and merged quickly to minimize the chance of conflicts. These still do happen occasionally, we just deal with them as they come up.
Whilst there’s been some downsides to the separate repositories all-in-all the benefits continue to outweigh the downsides but we constantly assess and at any point in time we can easily merge them if need be.