Testing web components vs. UI elements

UI testing refers to the approach of testing a web application as a whole from the user’s perspective by replacing backend requests with predefined mock responses. The frontend runs in isolation in the browser, without a real database or backend. This allows processes to be tested quickly, stably and in parallel without the effort of complete end-to-end testing.

Key Takeaways

• UI testing with mocked API responses replaces both component testing and most end-to-end testing for Felix Wunderlich’s team and delivers 280 tests in under three minutes on a 16 gigabyte VM.
• Testing the frontend against defined mock responses in isolation tests the entire application from the user’s perspective without having to boot up the backend, database or test data management.
• Playwright allows HTTP requests to be intercepted in the browser context and immediately replaced with prepared responses, enabling parallel test runs and cross-browser testing in different viewport sizes.
• The biggest setup risk is not in the test plan itself, but in the lack of centralization: CSS selectors, request definitions and response fixtures must be collected in one place from the beginning, otherwise every small UI change will result in dozens of test adjustments.

Component testing and end-to-end testing are not enough for frontends

Anyone testing a frontend is often caught between two worlds, neither of which fits. On the one hand, there is component testing: isolated, small, usually built as a unit test. On the other hand, end-to-end testing: complete, but slow and expensive to set up. There is a gap between the two, into which exactly what actually counts falls: the application as a user uses it.

Component testing hooks a single component into a small DOM using Jest, Mocha or a similar tool and tests it on its own. Sometimes composite tests are added that cover an entire form. The problem arises when rebuilding the UI. As soon as a component is moved or reassembled, rows of tests that nobody wanted to touch break.

End-to-end testing has the opposite problem. They run against a dockerized environment with its own database and test data management. That is time-consuming. Covering individual UI parts or error cases there is not economically viable. And if the last step fails after ten minutes of running, the game starts all over again.

Testing the frontend as an entire application in isolation

The approach that closes the gap tests the frontend as a complete application from the user’s perspective without starting up the real backend. The application runs in a browser context, as provided by Playwright, Cypress or Test Café. In this context, the requests that would otherwise be sent to backends, APIs or databases can be intercepted.

Instead of starting the real system, the test replaces the responses with predefined mock responses. The front end believes it is talking to the real system, but runs completely encapsulated. This allows you to test the entire application as a user, not just fragments of it.

Felix Wunderlich has introduced this approach at Volkswagen’s Software Development Center in Wolfsburg, where his team builds software for workshops. The technical implementation with Playwright is straightforward: in the tester, you define for a route that it returns a specific mock response to a specific request. That’s all you need for a functioning front end at first.

If I test my frontend as a real application from the user’s perspective in isolation, in parallel and quickly, then I basically have all the gains I can imagine.

Felix Wunderlich

Why going through the entire operating chain is an advantage, not a detour

The test operates the application as a user would, including all the steps before it. In the case of a widget with five steps, the test actually completes all five, even if it only wants to check the shape in the last step. At first glance, this seems unintuitive, almost wasteful.

The benefit lies in the state of the application. Running through the wizard from step to step ensures that the internal application state of the front end remains valid throughout the entire chain. This is exactly what saves the tinkering with artificially set intermediate states and the associated mocks.

Validations, different results, outgoing requests in the last step: all of this can be scripted and tested individually. The procedure is surprisingly fast because the steps beforehand are not the expensive part.

UI testing doesn’t have to be slow and unstable

Slowness and flakiness are considered the standard objections to UI testing. Both melt away significantly with mocked responses. Because there are no real backend responses, many tests can be run in parallel.

The practical figures: 280 UI tests run in under three minutes on a virtual machine with 16 gigabytes in the pipeline. That’s fast for this amount.

The approach is even more stable. The tests run across different browsers and in different sizes. This means that a bug that shows up in a certain Firefox version is already noticed during testing, not just in production. What would otherwise be noticed late and by chance becomes explicit.

What the approach brings for quality

The main benefit is security with every change. After every change, no matter how small, it is certain that the UI as a whole will continue to function from the user’s perspective. You can improve the code quality of the front end, run all tests at the end and rely on the green result.

This was not possible with individual component tests. There, when in doubt, the E2E test ran for ten minutes, the last step failed and everything started all over again. The change has abolished this loop.

As a result, there is no longer any component testing in the team. During the migration, all end-to-end testing that was not relevant to the user flow or the overall system was removed and transferred to UI testing.

Comparison: three test types for the frontend

Where the approach hurts: duplication and setup

Two areas have turned out to be unpleasant. The first is duplication with shared components. A button with asynchronous operation, loading spinner and green hook can appear in three places in the user flow. Then there is a test in three places that checks the same thing.

This contradicts the desire not to write anything twice. In a more complicated case, this could be resolved by separating the components. Nevertheless, the authorization question remains in the team as to whether the same test is really necessary three times.

The second point is the maintenance of the setup. When a CSS selector changed, dozens of tests had to be adapted. This resulted in a clear lesson for the setup.

How to build the setup so that changes don’t fall through

Before you start, take a close look at your UI and write down what it communicates with in the background. This overview is the basis for everything else.

Then collect centrally what else is scattered across the tests:

• the CSS selectors of the UI elements in one place
• the requests in one place
• reusable response images and tester data images as building blocks

This central setup is a lot of work at the beginning and not the prettiest. The benefits become apparent afterwards. If a backend API changes and sends a different response, you adjust the response screen in one place. As long as the change does not affect the UI, everything continues to run as before.

For an existing product with existing components and end-to-end testing, the setup effort is tough at the beginning. Nevertheless, it is well worth it.

An experiment beats a fundamental debate

The idea prevailed because it started as an experiment, not a requirement. The pain was felt daily, everyone in the team felt it. The migration from too many end-to-end tests to UI testing was manageable in terms of effort. So it was tried out.

An experiment is allowed to fail. If it fails, you stick with the old pain or look for another solution. In this case, it worked, and it was precisely this successful experiment that created full acceptance within the team.

The environment helped. At the Software Development Center, the teams own their products and try to build the best they can. If you want to try out something new, there is room to do so.

What’s coming up next

More tests mean more runtime at some point. With 500 UI testers over several years of product development, even these become slower. Simply throwing a bigger machine into the pipeline is not a satisfactory answer for an engineer: you’re throwing money at the problem instead of solving it.

The obvious direction is sharding, i.e. splitting up the tests and pushing parallelization further. It remains to be seen how far this can be taken, but there is room for maneuver.

The greater leverage lies in dissemination. The approach should be used in other products and, in the long term, UI testing could be accepted across several tools. Many colleagues go along with the idea, but are attached to their preferred tools. If the concept is accepted across tools, it could become the new standard way of testing a UI.