Stubbing the Back-end

What’s the matter with E2E tests? Well, they:

• They are slow: in the previous chapter, we dedicated a lot of attention to reducing the test duration but still they are slow.

• They do not allow the front-ender to work without a back-ender which greatly limits testing.

• They make edge cases replication difficult.

E2E tests are not feasible for front-end testing. Although they are important we cannot rely on them too much. This is why E2E testing is at the top of the testing pyramid. They give you the most confidence of any test, but they are very expensive in terms of writing, maintenance, and stability.

Going down the testing pyramid we can also find integration tests (where a part of the application is tested) and unit testing (a single unit/module test). Cypress allows us to write another test type easily: UI Integration Tests. The goal is to test the entire front-end app but without a real back-end. All the AJAX requests are stubbed with static responses. The main advantages are:

• Extreme speed. Cypress responds to the front-end AJAX requests in hundredths of a second.

• Front-end testing independence. We test the front-end while developing the front-end, meaning we do not need to delay the front-end testing due to the back-end.

• Testing confidence: testing the whole front-end in a browser gives you more confidence than a JSDom test with the terminal.

• Edge cases replication. With static responses, you can simulate (or reproduce, if you’re analyzing a bug) every edge case in a while.

Please note an important terminology difference:

• A stub is a static response used to “replace” the server.

• A mock is a simplified version of the back-end. It has the same APIs (from a front-end perspective) but with the minimum complexity needed to simulate the real back-end functionalities.

Implementing the first UI Integration test

Let’s analyze the signup flow.

Our E2E signup flow is as follows :