Frontend Testing for Busy Engineers: A Guide

Frontend developers often work on projects with no tests or so few that they make little difference. In this article, we’ll explore how to get the maximum impact from tests with minimal effort, why the classic testing pyramid doesn’t always fit frontend development, and which practices help test web applications effectively without unnecessary hassle. What Should We Test on the Frontend? Before we dive into testing, let's try to understand what parts a typical frontend application consists of. This will help us know what exactly we want to test in it and what kind of tests we should focus on. Let's consider a fairly typical frontend application built on React. React HTML/JSX Markup: JSX markup, React components, CSS — everything responsible for the structure and appearance of the UI. Requests to the backend API: fetching and mutating data, often using libraries like React Query or SWR, and sometimes via state manager side effects (RTK Query, Redux Sagas). State management: involves storing and modifying data on the client, whether it's the application's global state (e.g., via Redux, MobX, Context API, or other storage) or the local state of individual components. Frontend business logic: the part of a product's logic implemented on the client side. It can include data validation, calculations, and the application of interface display rules based on different states. HTML/JSX Markup: JSX markup, React components, CSS — everything responsible for the structure and appearance of the UI. HTML/JSX Markup Requests to the backend API: fetching and mutating data, often using libraries like React Query or SWR, and sometimes via state manager side effects (RTK Query, Redux Sagas). Requests to the backend API React Query SWR RTK Query Redux Sagas State management: involves storing and modifying data on the client, whether it's the application's global state (e.g., via Redux, MobX, Context API, or other storage) or the local state of individual components. State management Redux MobX Context API Frontend business logic: the part of a product's logic implemented on the client side. It can include data validation, calculations, and the application of interface display rules based on different states. Frontend business logic: Modern web applications' frontend code consists of fairly standard parts. Many complex tasks (such as data fetching, state management, and component libraries) are solved using well-established tools. Where should we focus our testing efforts? Should we verify that the UI renders correctly? Or should we concentrate on ensuring that components behave as intended? Is it worth writing tests for API calls and response handling? And what about state management—should we test how the application's state changes in response to different user actions? Let's start by looking at the main types of testing and try to determine where to focus most of our effort. The Classical Approach to Tests: What Tests Are and What They Are Used for The traditional model used in automated testing is called the testing pyramid. testing pyramid Unit tests - check the correctness of the work of separate functions and components. Such tests are usually the most numerous; they are easy to implement and run. Integration tests - test the interaction of several modules with each other. Frontend integration testing most often means testing individual pages or large parts of the application in isolation from the backend API E2E-tests (end-to-end) - These tests check applications by performing user actions in the browser. They test the whole application - frontend and backend. These tests are the hardest to run and are traditionally the least required. Unit tests - check the correctness of the work of separate functions and components. Such tests are usually the most numerous; they are easy to implement and run. Unit tests Integration tests - test the interaction of several modules with each other. Frontend integration testing most often means testing individual pages or large parts of the application in isolation from the backend API Integration tests E2E-tests (end-to-end) - These tests check applications by performing user actions in the browser. They test the whole application - frontend and backend. These tests are the hardest to run and are traditionally the least required. E2E-tests (end-to-end) The basic idea of the pyramid is that tests closer to the base (unit tests) are the easiest to implement and run, so they are usually the most numerous. Tests at the top of the pyramid (E2E) are more complex, slower, and generally fewer than the others. In practice, strictly following this model is not always practical, especially for frontend development. Which tests are essential, and which can be skipped? Let’s try to figure it out. Is it Possible to Do Without Tests? Sometimes, the project team deliberately decides not to use automated tests on the frontend. This happens in quite different projects, and there may be several reasons. For example, in startups at a very early stage, the main thing is to release the product as soon as possible. In legacy projects, where there may be a culture of doing without tests, the code base has grown without test coverage from the beginning, and it is difficult and costly to introduce new tests, so the status quo is maintained. In such cases, we can ensure product quality and ease of development by setting up the following essential tools in the project: Static analysis. The easiest step is to set up strict linter rules, typing (e.g., TypeScript), and other tools that catch errors at the build stage. Ensure such checks are triggered before each commit (use husky and lint-staged) and during CI builds. Error Monitoring tools, such as the popular Sentry, Datadog, or Logrocket, will help us learn about errors as soon as they occur to the user. Static analysis. The easiest step is to set up strict linter rules, typing (e.g., TypeScript), and other tools that catch errors at the build stage. Ensure such checks are triggered before each commit (use husky and lint-staged) and during CI builds. Static analysis linter TypeScript husky lint-staged Error Monitoring tools, such as the popular Sentry, Datadog, or Logrocket, will help us learn about errors as soon as they occur to the user. Error Monitoring Sentry Datadog Logrocket This approach won't make your app bug-free, but it will increase the development productivity and allow the team to respond more quickly to issues that arise in the product. Sooner or later, the application's complexity will grow so great that manual regression testing before each release will be too time-consuming. At that point, we will return to the idea of automated testing and will have to choose which type of tests to focus on first. E2E-tests: How to Implement If we talk about practical frontend testing, the most valuable and effective kind is E2E testing, and here is why: E2E tests allow you to check if the application works as intended from the end user's perspective. This type of test checks the correctness of the application operation across the entire stack, from a button pressed to a database query. They relieve some of the burden on manual testers. For example, they can test any scenario in several different browsers simultaneously. E2E tests allow you to check if the application works as intended from the end user's perspective. This type of test checks the correctness of the application operation across the entire stack, from a button pressed to a database query. They relieve some of the burden on manual testers. For example, they can test any scenario in several different browsers simultaneously. Several popular tools for E2E Testing exist: Playwright, Cypress, and the slightly more outdated Selenium and Puppeteer. These tools allow you to implement tests to check user stories. Playwright Cypress Selenium Puppeteer Open the page, click the button, and check that the desired content appears. Perform basic user actions (such as authorization or form filling) and verify their success. Open the page, click the button, and check that the desired content appears. Perform basic user actions (such as authorization or form filling) and verify their success. A good practice is to use the Page Object pattern, which allows you to remove common elements and page actions from the test code. Fixing the PageObject code without touching the test code will be enough if the page changes. Page Object pattern import { test, expect } from '@playwright/test'; test.use({ storageState: 'playwright/.auth/user.json' }); import cases from './__fixtures__/case-users.json'; import { CasesPage } from './page-objects/CasePage'; test('cases: search find known case by name', async ({ page }) => { const casesPage = new CasesPage(page); await casesPage.goto() await casesPage.search(cases.slava.searchQuery); await expect(page.getByText(cases.slava.name)).toBeVisible(); await casesPage.getCaseLinkByName(cases.slava.name).click(); await expect(page.getByText('Profile')).toBeVisible(); }); import { test, expect } from '@playwright/test'; test.use({ storageState: 'playwright/.auth/user.json' }); import cases from './__fixtures__/case-users.json'; import { CasesPage } from './page-objects/CasePage'; test('cases: search find known case by name', async ({ page }) => { const casesPage = new CasesPage(page); await casesPage.goto() await casesPage.search(cases.slava.searchQuery); await expect(page.getByText(cases.slava.name)).toBeVisible(); await casesPage.getCaseLinkByName(cases.slava.name).click(); await expect(page.getByText('Profile')).toBeVisible(); }); Which parts of the application should you cover with E2E tests first? The first tests can be simple smoke tests: check that the application pages open after the deployment and display all the necessary elements. Because this type of test does not mutate the state on the backend, we can safely run it on the production environment. Next, you can focus on the critical path—the application's most important business functions. These can include authorization, order placement, etc. Next, increase your app's test coverage as much as possible and add tests for all new features. The first tests can be simple smoke tests: check that the application pages open after the deployment and display all the necessary elements. Because this type of test does not mutate the state on the backend, we can safely run it on the production environment. smoke tests smoke tests Next, you can focus on the critical path—the application's most important business functions. These can include authorization, order placement, etc. Next, increase your app's test coverage as much as possible and add tests for all new features. Common E2E Test Pitfalls Despite the tremendous advantages of E2Es, there are several challenges when using it: Flaky tests: Sometimes, E2E tests can crash unpredictably (network problems, animation and loading problems, race conditions). Modern tools like Playwright are almost free of such issues, but they will occur occasionally. It's hard to advise one thing here; you'll probably have to deal with it locally each time. Run speed: A complex E2E test usually takes much longer to run than a unit test. The overall run can take significant time if there are hundreds or thousands of tests. In this case, running tests in parallel and optimizing the environment helps. Besides, tests can be divided into several test suits and run as needed. Test Data. E2E tests require the application to be in a particular state at each run. You need to know in advance what data is in the database and what responses the API will return. This adds complexity and cost: to return the application to its original state before each run of e2e tests, you must restore the database from snapshots/backups. Backend developers and DevOps will have to keep these snapshots up to date. Flaky tests: Sometimes, E2E tests can crash unpredictably (network problems, animation and loading problems, race conditions). Modern tools like Playwright are almost free of such issues, but they will occur occasionally. It's hard to advise one thing here; you'll probably have to deal with it locally each time. Flaky tests: Run speed: A complex E2E test usually takes much longer to run than a unit test. The overall run can take significant time if there are hundreds or thousands of tests. In this case, running tests in parallel and optimizing the environment helps. Besides, tests can be divided into several test suits and run as needed. Run speed Test Data. E2E tests require the application to be in a particular state at each run. You need to know in advance what data is in the database and what responses the API will return. This adds complexity and cost: to return the application to its original state before each run of e2e tests, you must restore the database from snapshots/backups. Backend developers and DevOps will have to keep these snapshots up to date. Test Data Sometimes, E2E testing is challenging to implement because of the problems with the data. For example, we don't know how to restore DB from snapshots yet (backend devs and DevOps promise to fix it tomorrow). Or the application uses a 3rd-party API, which we cannot use in our tests. In such a case, the simple and efficient way out is to turn the E2E test into an integration test where some or all network calls are mocked. When E2E Is Not Enough: Integration Tests Let's take our E2E test and rewrite it so that it accesses the mock API instead of the actual backend. import { test, expect } from '@playwright/test'; test.use({ storageState: 'playwright/.auth/user.json' }); import casesList from './__fixtures__/case-list.json'; import { CasesPage } from './page-objects/CasePage'; test('cases: search find known case by name', async ({ page }) => { await page.route('/api/cases', async (route) => { await route.fulfill({ json: casesList }); }); const firstCase = casesList[0]; const casesPage = new CasesPage(page); await casesPage.goto() await casesPage.search(firstCase.searchQuery); await expect(page.getByText(firstCase.name)).toBeVisible(); await casesPage.getCaseLinkByName(firstCase.name).click(); await expect(page.getByText('Profile')).toBeVisible(); }); import { test, expect } from '@playwright/test'; test.use({ storageState: 'playwright/.auth/user.json' }); import casesList from './__fixtures__/case-list.json'; import { CasesPage } from './page-objects/CasePage'; test('cases: search find known case by name', async ({ page }) => { await page.route('/api/cases', async (route) => { await route.fulfill({ json: casesList }); }); const firstCase = casesList[0]; const casesPage = new CasesPage(page); await casesPage.goto() await casesPage.search(firstCase.searchQuery); await expect(page.getByText(firstCase.name)).toBeVisible(); await casesPage.getCaseLinkByName(firstCase.name).click(); await expect(page.getByText('Profile')).toBeVisible(); }); In fact, this test is almost identical to our E2E test, except that we control the API data source. You can use playwright’s built-in page.route hook, or mocking libraries such as msw to intercept api requests. built-in page.route msw Let's see which features of our test have changed and which have not. We still test our application through a user's POV in a real browser. The tests use the same set of tools: playwright/cypress. But now we are testing the frontend in isolation from the backend: We no longer need a complex data set-up before each test run. To run the tests, we only need to deploy the frontend. Such tests run faster than E2E tests. We no longer need a complex data set-up before each test run. To run the tests, we only need to deploy the frontend. Such tests run faster than E2E tests. However, we must ensure the mock API does not diverge from the actual backend. It is worth remembering that integration tests have lower reliability guarantees than E2E tests, as they test only the frontend, not the entire stack. When Do You Need Unit Tests, and How Do You Implement Fewer of Them? After all this, it may seem that unit tests on the frontend do not play a significant role. However, there are cases when you can't do without them. Complex logic: For example, a non-trivial cost calculation function, a route building module, and advanced form validation with multiple rules - all of this is better covered by separate unit tests. Library code and reusable utilities: Tools that can be used in different product parts, perhaps by other teams. For example, functions to handle dates, a solution to normalize data from the API, and the like. Refactoring and legacy code support. Before refactoring, you may write tests fixing the current code behavior and then safely rewrite the implementation. If all the tests pass after the changes, the original functionality has been preserved. Complex logic: For example, a non-trivial cost calculation function, a route building module, and advanced form validation with multiple rules - all of this is better covered by separate unit tests. Complex logic Library code and reusable utilities: Tools that can be used in different product parts, perhaps by other teams. For example, functions to handle dates, a solution to normalize data from the API, and the like. Library code Refactoring and legacy code support. Before refactoring, you may write tests fixing the current code behavior and then safely rewrite the implementation. If all the tests pass after the changes, the original functionality has been preserved. Refactoring legacy How can we minimize the number of unit tests without sacrificing product quality? The guiding principle is to test only what is of real value and is not covered by other types of tests. You should not write unit tests for trivial functionality. For example, a test that checks that the button component renders child elements. If a well-supported library exists to solve a typical problem, you should choose it rather than code and support the solution yourself. It is also not worth chasing code coverage metrics. In practice, high values of this metric do not guarantee high product quality. You should not write unit tests for trivial functionality. For example, a test that checks that the button component renders child elements. If a well-supported library exists to solve a typical problem, you should choose it rather than code and support the solution yourself. It is also not worth chasing code coverage metrics. In practice, high values of this metric do not guarantee high product quality. Recap: An Optimal Automated Testing Strategy for the Frontend Efficient frontend testing does not mean implementing a large number of tests and aiming for abstract coverage metrics. On the contrary, the key is a deliberate approach and the ability to highlight critical scenarios and sections of the application. Use static analysis and error monitoring tools: Sometimes, when there is no time for tests at all, the best solution is to rely on strict typing, linter, and monitoring tools. They help you catch errors before they get to production. Prioritize: Start with E2E tests that test key user scenarios. This approach will provide confidence that core business functions are working across the entire stack in your application, not only the frontend. Use integration tests: If E2E tests are hard to implement because of the data (backend issues, external APIs), don't be afraid to replace them with integration tests with mocked API. Minimize the number of unit tests: Write them only for really complex or critical pieces of logic. Refuse to write tests for simple components or functions. Use proven libraries and frameworks to solve typical tasks. Use static analysis and error monitoring tools: Sometimes, when there is no time for tests at all, the best solution is to rely on strict typing, linter, and monitoring tools. They help you catch errors before they get to production. Use static analysis and error monitoring tools: Prioritize: Start with E2E tests that test key user scenarios. This approach will provide confidence that core business functions are working across the entire stack in your application, not only the frontend. Prioritize Use integration tests: If E2E tests are hard to implement because of the data (backend issues, external APIs), don't be afraid to replace them with integration tests with mocked API. Use integration tests: Minimize the number of unit tests: Write them only for really complex or critical pieces of logic. Refuse to write tests for simple components or functions. Use proven libraries and frameworks to solve typical tasks. Minimize the number of unit tests: Remember, practical testing is not about quantity; it is about focusing on what's most important.