I’m excited to be presenting at this year’s ATTAC (Australian Test & Tech Automation Conference) in Melbourne on 24th May on establishing automated e2e web testing in Node.js:
Node.js is so hot right now. Whether you’re looking at quality engineering jobs at a new and upcoming startup, or at an established corporate, chances are you’ll see Node.js on the tech stack. But establishing automated e2e web testing in Node.js is hard since it’s very different to traditional web automation technology. In this talk Alister will use nearly four years of Node.js experience to bring clarity to the somewhat confusing Node.js landscape, going into detail on things like asynchronous promises, ECMAScript transpiling, npm vs yarn and monorepos.
Adventures of end-to-end automated web testing in Node.js #
I attended the first conference last year in Melbourne and loved the format (single day, single track), affordability (tickets from AUD$199) and technical subject matter.
Early bird tickets are on sale now. I hope to see you there!
We use CircleCI to run our automated end-to-end (e2e) tests for WordPress.com.
We run our tests pretty frequently – not only against every individual change coming through – but we also run them in Production every time someone deploys (about 30 times per day) – as well as every 6 hours to cover weekends and quiet periods of deployments to make sure our hardware and other changes haven’t impacted our key customer flows.
Originally CircleCI didn’t support scheduled jobs so we set up our own infrastructure to schedule jobs to call the CircleCI API which executed the tests.
Fortunately version 2.0 of the CircleCI config now natively supports scheduling jobs which is exactly what we want to do. Since it also uses cron, the default scheduling format, it was very easy to create our jobs in CircleCI.
A great presentation from the recent 2018 Selenium Conference with a few shout-outs to this blog. I really like what Wes and Kurt were able to achieve using AWS Lambda – amazingly fast e2e tests running in parallel.
I have dodged the AngularJS /Protractor bullet for many years now. May last foray, some 5 years ago, was a cluster to put it mildly! Cucumberjs/Angularjs/Protractor/chai/mocha/ the stack was in its infancy and failed miserably!! Many cycles were spent pulling fixes from our own repos instead of waiting for PRs to get done. This was in stark contrast to the ease and stability of the automation I wrote using Watir-Webdriver and eventually Watir.
I am now faced with automating the regression test cases for an Angularjs App.
Question: Do I finally jump back into the using stack that almost caused me to lose my mind, or is it possible to use Watir/Selenium to build out meaningful e2e UI automation for an angularjs app as we dawn on 2019?
It’s still my opinion in 2018 that writing e2e tests in Node using either Protractor or WebDriverJs is still more difficult than using Watir in Ruby.
Sure using async functions with await commands makes things easier than before (see examples in our project), when you would have first come across Protractor, but I still feel like there’s a lot of catching up to do to get to the stability and ease-of-use of Watir.
My decision would come down to whether others on your project are going to be comfortable maintaining tests in ruby – if they are I’d use Ruby and Watir, otherwise I’d revisit Protractor if they really want to use Node.
“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?
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.
Update March 2020: I no longer work remotely but I consider these tips are still relevant, particularly since COVID-19 has meant that many employees around the globe are now required to work from home. I also wrote a higher level essay on reflection of working from home from an employee’s perspective.
September 2018 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.