End-to-End (E2E) tests are the most important tests for a piece of software because they are the technical implementation of the contract between the software creator and its users. If all your E2E tests pass, then the contract is fulfilled.
Linus Torvalds, the creator and maintainer of Linux, one of the biggest open-source projects, famously said “WE DO NOT BREAK USERSPACE!” (an opinion which he consistently expresses). He values:
- Not breaking the contract between the kernel and user-space programs
- Don’t make changes to the contact that’s incompatible with previous contracts
Now, I’d bet the software you’re writing have fewer dependents than the Linux kernel, and you can change the contract more freely, but the purpose of this article is to drill home the point that you should not break contracts.
Code quality may not be high, test coverage may be low, performance may be dismal, but as long as you fulfill the contract, your software is working and not broken, and that’s the most important.
N.B. I am not suggesting E2E tests are the only tests you need (that’d be a pretty low bar), but it is the most important.
What most people misunderstand is what is meant by ‘End-to-End’. I define E2E tests as ’tests that emulate the actions of the end-users’. If you are building:
- a function - the E2E test is the same as the unit test for that function.
- a library/package - the E2E test would be the unit or integration tests that tests the public interface for your library.
- a website/app - the E2E test would be the automated UI tests done with tools like Selenium or Cypress.
- an API - the E2E test would involve a call to the API, which should be based on an OpenAPI specification or Postman Collection.
