AMA: Separate Repository for e2e Tests?

Liam asks…

“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”

My response…

Thanks for your question Liam.

We have reasons for and benefits in having the e2e tests in a separate repository:

  1. The e2e tests test the entire 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;
  2. 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:

  1. How do we make sure e2e tests know about incoming AB tests?
  2. 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:

Screen Shot 2018-09-19 at 3.31.47 pm
example prompt

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:

Screen Shot 2018-09-19 at 3.38.29 pm
e2e Test Results against a Calypso 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.

Three Years of Working From Home

This month marks my three year anniversary (Matticversary) at Automattic, which  means I have been solely working from home for three years now.

Working from home every day can at times feel like either, or both, the best thing in the world, or the worse thing ever invented. I personally don’t believe that full-time working from home is suitable for everyone as I’ve found it orders of magnitude more difficult than working in an office environment.


It’s taken me almost three years to really work out what works well for me as a full time “telecommuter” – and I thought I’d use my work anniversary to share some of these.

Like anything, you’re mileage my vary, but these tips have definitely helped me over the years.

    1. Create a morning routine: since I don’t commute I’ve found it hard to mentally separate finishing non-work time and starting work time in the morning which is something a commute provides (without you realising). Since I have a flexible schedule I make sure that in the mornings I have a routine. I am lucky enough to live right next to a beautiful forest so I go for a 4-5km walk each morning which not only provides exercise and nature exposure benefits but symbolises to my brain that work  begins at the end of my morning walk. This can sometimes be hard to justify to myself as some of my colleagues are finishing up around the same time as I am walking – and I may miss checking in with them – but I definitely need this morning routine.
    2. Dedicate a home office space: as a family of five we live in a small cottage so it’s hard to justify a dedicated home office space in our home, but I’ve found it vital for separating my home and work lives. When I’m in the office I am working – when I am not in the office I am not working. My three children know they can’t play in my office – if I take a break to spend time with them I come out of my work space. I read in The Organized Mind book that “students who studied for an exam in the room they later took it in did better than students who studied somewhere else”. I believe this is due to the mental association.
    3. Dedicate a computer just to work: again this seems luxurious but having a dedicated work computer, or at least a dedicated computer profile/account, creates a good association between that computer and work. From The Organized Mind book again: “Create different desktop patterns on them so that the visual cues help to remind you, and put you in the proper place-memory context, of each computer’s domain“.
    4. Disable app notifications on your phone: unless I’m an in person work meetup (which happens a few times a year) I disable app notifications on my phone for work apps (like Slack, WordPress and GMail) which means I rarely check or open those apps outside of my work environment (see #2 and #3).
    5. Avoid checking work in bed: it’s very tempting to check on work things on my mobile phone in bed, particularly when you work for a global 24×7 365 company like I do, but this disrespects the importance of sleep in our lives. As Matthew Walker, one of the world’s leading sleep scientists says in Why We Sleep: “The silent sleep loss epidemic is the greatest public health challenge we face in the twenty-first century in developed nations. If we wish to avoid the suffocating noose of sleep neglect, the premature death it inflicts, and the sickening health it invites, a radical shift in our personal, cultural, professional and societal appreciation of sleep must occur.” You can use a morning ritual (see #1) to signify when you’ll start checking work things, instead of opening your eyes in bed and checking work immediately.
    6. Create an end of work day ritual: I am my most productive in the hours leading to dinner time so I use dinner time as my end of the work day ritual when I transition from working to not-working. I also have a couple of apps on my phone I like using and I don’t let myself use them during the day so I can signify at the end of the work day when I’m not working. Like a play reward that a working dog gets when they’re finishing working.
    7. Find social activities outside of work: working from home all the time can get very, very lonely and you can feel particularly isolated – especially working for a global company with flexible work hours, and having no team members close to your timezone. It’s important to find social activities outside of work as working in an office a lot of this is a given – even something like chatting to someone in the coffee room you won’t get working from home. I’ve tried attending Toastmasters, hiking groups and making sure I get along to meetups and user groups. Also I recommend meeting up with friends and ex-colleagues for lunches – travelling to where they work. This gives you a good break from working from home and can reduce the feeling of isolation.
    8. Spend some time away from home on holiday: this is one of the most expensive parts of working from home in my opinion, and it is easy to blow all the cost savings of not-commuting on holidays away from home that you need so you don’t feel like you’re at work. If you take time off and just stay at home (sometimes known as a “staycation”) I have found I don’t feel like I’ve really disconnected from work as I’m still thinking about work being home (even though I have a dedicated workplace – see #2). I’d love to work out a way to solve this one without spending more and more money on holidays away from home.
    9. Have something to listen to: I listen to electronic dance music mixes on Mixcloud all day long – but your tastes may vary. This provides a soundtrack for working.
    10. Set yourself a daily goal: I work in a Results Only Work Environment where my employer doesn’t care so much about my hours as long as I achieve results. This is both good and bad (I could write an entire post on it) but you need to be disciplined and set your set a daily goal and stick to it. Sometimes this means working longer than you planned, other times it’s important if you achieve your daily goal earlier than expected you finish earlier than expected to make up for all those other times. Otherwise you can get caught in a never-ending work loop.
    11. Close loops: working in a distributed work environment I find I have lots of different things on the go at any one time – this is because I might be expecting a reply or some work from someone else on something and everyone works different hours and lives in various time-zones. I find it’s important to re-visit all these “open loops” and close them, just so your mind doesn’t think about them anymore. This is sometimes a case of leaving a comment like “I didn’t hear anything back on it so I’ll close it” to close the loop – and remove it from your focus and bandwidth.
    12. Find tasks that you can finish to completion outside of work: most of the things I work on have a medium-to-long event horizon – or an indefinite horizon as I await asynchronous feedback – so I’ve found hobbies that I can finish completely in one attempt – gardening, cooking a meal, washing the car etc. are very important for my mental well-being as I get a good sense of accomplishment with these tasks and hobbies. See #11
    13. Getting things done creates motivation to do more things: when I lack motivation to start something I find the smallest thing that I can get done and complete that. The sense of accomplishment of getting something done motivates me to do more.
    14. Over-communicate: I can’t emphasise this enough – no one will see you in the corner of an office getting stuck on a problem – you need to constantly communicate everything you’re doing – good and bad. Communicating context creates empathy in a distributed team.
    15. Set expectations for family and friends: some people assume you’re not really “working” if you work from home. Setting aside a work space (#2) helps – but you’ll need to continually explain to people that even though you are at home you are actually at work.
    16. Don’t be afraid to ask ‘stupid’ questions: in a work from home environment there’s bound to be other people thinking the exact same thing as you – so ask away!
    17. Don’t be afraid to be a bit weird:Today you are you, that is truer than true. There is no one alive who is youer than you” (Dr Seuss)


That about covers it for now. As I said, working from home can be very rewarding, but it’s one of the hardest challenges I’ve ever faced, and after three years I’m still working at it!

AMA: Iterative vs Incremental Development

Mario asks:

I have a question to ask your post on iterative vs. Incremental Software Development:

In the incremental approach, the few features implemented in all of their requirements can be changed after user feedback? Or, does this only happen with the iterative approach?

My response:

Thanks for your question Mario. This can, and should, happen with both approaches, but I’d say the incremental approach is actually more likely to get customer/user feedback as it’s a more polished, albeit smaller, user experience, and therefore more likely to land in front of users. The painting analogy isn’t the best as the requirements and level of ‘done’ are pretty clear, but the general rule is to seek feedback as soon as possible, and both approaches are designed to do just that.

Avoiding LGTM PR Cultures


Making a code change when using a distributed version control system (DVCS) like Git is usually done by packaging a change on a branch as a “pull request” (PR) which indicates the author would like the project to “pull” the change into it.

This was, and is, a key part of open source projects as it allows outside contributors to contribute to a project in a controlled way, however many internal software development teams also work in this fashion as there are many benefits of this approach over committing directly to a shared branch or trunk.

I’ve seen the pull request approach have a positive impact on software quality since pull requests facilitate discussion through peer reviews and allow running of automated tests against every commit and change that is proposed to be merged into the default branch.

taken lgtm.jpg

What is a LGTM PR culture?

I’ve also seen some negative behaviours emerge when moving to pull request based development which I’ll call a LGTM PR culture.

LGTM is a common acronym found in peer reviews of pull requests which means “Looks Good To Me”, and I’ve seen teams let unsuitable changes through with LGTM comments without doing solid peer reviews and testing.

How do you know if you have a LGTM PR culture?

One way to “test” your peer review process is by creating PRs and leaving a subtle bug or something not quite right that you know about in the PR. When it gets reviewed do you get a LGTM? I did this recently and whilst the PR didn’t even do what it was meant to do I received a LGTM 😕


How can you move away from a LGTM PR culture?

It’s tempting to just tell everyone to do better peer reviews but it’s not that easy!

I’ve found there’s some steps that an author of a pull request can do to facilitate better pull request reviews and lead towards a better culture.

1. Make pull requests as small as possible:

The smaller the pull request the more likely you’ll get specific and broad feedback on it – and you can then iterate on that feedback. A 500 line change is daunting to review and will lead to more LGTMs. For larger refactorings where there’ll be lots of lines changed, you can start with a small focussed change and get lots of review and discussion, and once the refactoring is established with a smaller example you can easily apply that feedback to a broader impact PR that won’t need as much feedback as you’ve established the new pattern previously.

2. Review your own pull request

Review your own work. This works best if you do something else then come back to it with a fresh mind. Anything you’re unsure about or doesn’t look right leave it as a comment on your own PR to encourage other reviewers to look closely at those areas also.

3. Include clear instructions for reviewing and testing your pull request

A list of test steps is good as well as asking for what type of feedback you’d like – you can explicitly ask reviewers something like “please leave a comment after your review listing what you tested and what areas of the code you reviewed.” This discourages shortcuts and LGTMs.

4. Test your peer review process – see above.


Developing software using pull requests can mean much higher quality code and less technical debt due to the feedback on peer reviews that accompany pull requests. As an author you can take steps to ensuring pull requests are easy to review and encourage a culture of effective peer reviews.

npm ci

I recently discovered npm ci which you can use instead of npm install when running a node project on continuous integration (CI) system and want to install your npm dependencies. It does this in a more lightweight, more CI friendly way.

If you use npm test to run your tests, this can be shortened to npm t (much like npm i is npm install), and therefore you can run npm cit to install dependencies and run tests in CI.

Running Mocha e2e Tests in Parallel

I recently highlighted the importance of e2e test design. Once you have well designed e2e tests you can start running them in parallel.

There are a couple of approaches to scaling your tests out to be run in parallel:

  1. Running the tests in multiple machine processes;
  2. Running the tests across multiple (virtual) machines;

These aren’t mutually exclusive, you can run tests in parallel processes across multiple virtual machines – we do this at Automattic – each test run happens across two virtual machines, Docker containers on CircleCI, each of which runs six processes for either desktop or mobile responsive browser sizes depending on the container.

I have found running tests in multiple processes gives best bang for buck since you don’t need additional machines (most build systems charge based on container utilisation) and you’ll benefit from parallel runs on a local machine.

We write our e2e tests in WebDriverJs and use Mocha for our test framework. We currently use a tool called Magellan to run our e2e tests in separate processes (workers), however the tool is losing Mocha support and therefore we need to look at alternatives.

I have found that mocha-parallel-tests seems like the best replacement – it’s a drop in replacement runner for mocha tests which splits test specification files across processes available on your machine you’re executing your tests on – you can also specify a maximum limit of processes as the command line argument --max-parallel

There is another parallel test runner for mocha: mocha.parallel – but this requires updating all your specs to use a different API to allow the parallelisation to work. I like mocha-parallel-tests as it just works.

I’ve updated my webdriver-js-demo project to use mocha-parallel-tests – feel free to check it out here.

Running e2e Tests in Parallel

One of the best ways to speed up your end-to-end (e2e) tests is to start running them in parallel.

The main issue I see that prevents teams from fully using parallelism for their e2e tests is lack of test design. Without adequately designed e2e tests – which have been designed to be run in parallel – parallelism can introduce non-deterministic and inconsistent test results – leading to frustration and low-confidence in the e2e tests.

This is often the case when teams go about directly converting manual test cases into automated e2e tests – instead of approaching e2e test automation with a specific end-to-end design focus.

Say you had a manual test case for inviting someone to view your WordPress blog:

  1. Enter the email address of the person you’d like to follow your site
  2. Check the list shows a pending invite
  3. Check your email inbox shows a pending invite
  4. Open the email, follow the link and sign up for a new account

When you’re manually testing this in sequence it’s easy to follow – but as soon as you start running this in parallel, across different builds, and with other tests things will most likely start failing.

Why? The test isn’t specific enough – you may have multiple pending invites – so how do you know which one is which? You can only invite someone once, how do you generate new invite emails? You may receive multiple emails at any one time – which one is which? And more.

With appropriate e2e test design you can write the e2e test to be consistent when run regardless of parallelism:

  1. Email addresses are uniquely generated for each test run using a GUID and either a test email API like Mailosaur or Gmail plus addressing; and
  2. The pending email list has a data attribute on each invite clearly identifying which email the invite is for and this is used to verify pending email status; and
  3. The inbox is filtered by the expected GUID, and only those emails are used. Etc.

Once you have good e2e test design in place you’re able to look at how to speed up e2e test execution using parallelism. I’ll cover how to do this in my next blog post.