I’ve been blogging on WordPress.com for over nine years and I’m very happy with my decision to become both a WordPress.com user back then, and a WordPress.com (Automattic) employee in 2015.
Feature toggles aren’t just for production code. Feature toggles are also a powerful technique to change the behaviour of your automated end-to-end tests without changing code.
When I talk to people about my job at Automattic, most of them can’t really comprehend how it can possibly work since it’s so different to what they see as a ‘normal job’.
One of the many, many things I love about working at Automattic is the being part of a company that sees huge value in everyone spending time doing customer support, and acts on it:
“When you join full-time, you’ll do customer support for WordPress.com for your first three weeks and spend a week in support annually, for evermore, regardless of your position. We believe an early and ongoing connection with the people who use our products is irreplaceable.”
Automattic’s Work With Us Page
Every single bit of that statement is true: I did three full weeks when I joined last September, and I’ve already done an additional week this year.
If you would like to read more about our e2e tests for WordPress.com you can do so over on the Automattic Engineering blog where I have recently published an article for the WordPress developer community.
Clark Hamilton asks…
What do you think about running e2e GUI tests continually and displaying the results on a real-time dashboard? We could build such a system but maybe there is an open-source solution we don’t know about. We’re using Mocha with webdriverio and found your articles useful. Appreciate your thoughts!
- on every deploy to WordPress.com (tens of times per day); and
- every 6 hours from UTC 0:00 (to pick up issues like connectivity that happen independent of deployments); and
- every time a change to the e2e tests is merged into the master branch.
We do this using CircleCI which connects to Github to perform #3 automatically. With #1 and #2 we use the CircelCI API to trigger builds on the master branch during our deploy process and every 6 hours using a cron job.
As for a dashboard, we use the CircleCI results page which shows the history of each run, and we also have some slack channels set up which also get real time notifications of results, and any tests that fail (including screenshots). The way we do this is in our source code.
Since we’re a 100% distributed company with no offices we don’t have any build lights/monitors etc. for an office space, we just individually use our own channels to monitor these test results.
I am very pleased to announce that all of our e2e tests for the WordPress.com platform are open source as of this morning. This is following in the footsteps of the WordPress.com Calypso front-end which is also open source.
“The quality of our code and our product depend on the amount of feedback we get and on the amount of people who use them. If we’re developing behind closed doors, we are putting artificial limits to both.
We have done our best work in the open, let’s continue working this way.”
~ Matt Mullenweg, CEO Automattic
Our ongoing development of these tests is in the open. So please feel free to take a look through our e2e tests, their CI results, and fork them, provide us some feedback, or use some of our ideas. And pull requests are always welcome 😀