E2E testing is a more extreme form of integration test where, instead of testing individual integrations between modules, we'll test the entire system, usually by executing a series of actions that would happen in reality to produce a given result. These tests are sometimes also called functional tests because they are interested in testing areas of functionality from the user's perspective. Well-constructed E2E tests give us confidence that our entire system is working correctly, but are most valuable when combined with more granular unit and integration tests so that faults can be more quickly and precisely identified.

Here's a quick lowdown of the benefits of writing E2E tests:

• Correctness and health: E2E tests give you a clear insight into the general health of a system. Since many individual parts will effectively be tested via the typical E2E test, its success can give you a good indication that things are okay in production. Granular unit or integration tests, while very useful in their own way, don't give you this kind of systemic insight.
• Realistic effects: Via E2E tests we can tryout more realistic circumstances, emulating the way our code will run in the wild. By emulating the flow of a typical user, an E2E test can highlight potential issues that more granular unit or integration tests might not reveal. An example of this would be when there are race conditions or other timing issues that can only be revealed when a code base is made to run as one consolidated system.
• More holistic view: E2E tests give developers a holistic view of a system, enabling them to reason more accurately about how distinct modules work together to produce a working user flow. This can be incredibly valuable when trying to build a full understanding of how a system operates. Much like both unit and integration tests, E2E tests can serve as a form of documentation.

There are challenges involved in crafting E2E tests, however:

• Performance and time costs: E2E tests, because they involve the activation of many individual pieces of code immersed in realistic environments, can be quite expensive in terms of time and hardware resources. The time that E2E tests take to run can impede development, and so it's not rare for teams to avoid E2E tests for fear of a slowed development cycle. 
• Realistic steps: Accurately emulating real-life circumstances in an E2E test can be a challenge. Using fake or made-up situations and data can still provide a realistic enough test but can also provide you a false sense of confidence. Since E2E tests are scripted, it's quite common to not only rely on fake data but to have actions conducted in an unrealistically fast or direct manner, missing out on possible insights you could gain by creating more human circumstances (repeat after me: always think of the user).
• Complex tooling: The point of an E2E test is to realistically emulate a user flow as it would exist in the wild. To accomplish this, we need good tooling that enables us to set up realistic environments (for example, headless and scriptable browser instances). Such tooling can be buggy or complicated to use and can introduce yet another variable to the testing process that can result in unrealistic failures (tools can give you false signals about whether things are really working).

E2E testing, although challenging to get right, can provide a level of insight and confidence that is hard to get from only unit and integration tests. In terms of automated testing procedures, E2E testing is the closest we can reasonably get to getting our software in front of real users. It is the least granular and most systemic way of discerning whether our software works in the way our users expect it to, which, after all, is what we're most interested in.