Writing E2E tests

In the previous section, we built and tested an API for booking event seats. Our tests exercised multiple layers of the application: the HTTP routes, the business logic, and the database. That’s why we confidently called them integration tests: they validated that the different components of the system worked correctly when integrated together.

But you might be wondering: why not call those tests E2E tests? After all, they covered a broad part of the system, and in many real-world projects, similar tests might even be labeled that way. Truthfully, that wouldn’t be wrong. The boundary between integration and E2E testing is often blurry, and there’s no single universal definition that fits every project. So, the important thing is to draw the line deliberately, and in this book, we draw that line at the user.

To know what constitutes a proper E2E test, we first need to understand: what is the product, and who is the user? E2E testing is...