Part eighteen of a series of posts about automated testing.

As we discussed previously, the standard advice is to minimize the number of browser-based end-to-end tests written. The advantage of e2e tests is that they mimic a real user; the disadvantage is that they tend to be slow and unreliable.

Still, there are some system elements that are very unusual to exercise in other types of test; you can test the deployment process (assuming you deploy into a testing environment very similar to production), and you can test that things like network configuration and DNS names are wired up correctly.

In the context of web applications, e2e tests involve automating browser actions, to navigate to URLs on the site, and “click” page elements to simulate a real user. There are also systems which can orchestrate e2e tests for mobile applications, e.g. Appium or Calabash.

The de-facto standard for browser automation is the WebDriver protocol, which grew out of the Selenium project. These days all major browsers have solutions for implementing the protocol - you can talk to a REST API and have your browser perform actions on your behalf.

It is not straightforward to keep end-to-end tests maintainable, so in the next posts we will share some approaches we have found helpful for writing and organising these tests.

Further reading