Lesson 1 of 87 min read
How a React app works, for testers
Many web apps you test are built with React. A React page is made of small reusable pieces called components that redraw themselves when data changes. Knowing this helps you understand flaky UI, stale screens and where tests belong. This lesson explains React in tester language and shows the testing layers used on React projects.
Key takeaways
- 1A component is a function that takes inputs (props) and returns what the screen should show. Pages are trees of components.
- 2State is data a component remembers (an open menu, form values, loaded items). When state changes, React redraws that part of the screen.
- 3Many React apps load data after the first paint, so elements appear a moment later. Tests must wait for them, not sleep.
- 4Testing layers: unit tests for pure logic, component tests (Vitest/Jest + React Testing Library), and end-to-end tests in a real browser (Playwright, Cypress).
- 5Component tests are fast (milliseconds) and catch UI logic bugs early; end-to-end tests prove the full flow works with the real backend.
A product page as a component tree
<ProductPage> <Header cartCount={2} /> <ProductDetails product={...}> <PriceTag price={499} discount={10} /> -> shows 449.10 <AddToCartButton disabled={outOfStock} /> </ProductDetails> <Reviews productId="p1" /> -> loads after paint </ProductPage> Test ideas per piece: PriceTag : discount maths, rounding, 0% and 100% discount AddToCartButton : disabled when out of stock, calls onAdd once Reviews : loading text, empty state, API error message
Go deeper
Expert notes beyond the basics
- 01
Single-page apps and testers
React apps usually load one HTML page and swap content with JavaScript. The URL can change without a full reload, so 'page loaded' events are less useful. Wait for the content you need (a heading, a row) instead of waiting for navigation to finish.
- 02
The testing trophy
React teams often follow a 'trophy' shape: a base of static checks (TypeScript, linting), a few unit tests, many component/integration tests, and a small number of end-to-end tests. Component tests give the best mix of speed and confidence for UI logic.
- 03
Where QA adds value
Developers often write component tests for the happy path. Testers add value by listing edge cases and states: empty, error, slow, long text, permissions, keyboard use, and double actions. Even if you don't write the code, a list of states per component improves coverage.
Common mistakes to avoid
- - Using fixed sleeps because elements appear 'a bit later'.
- - Putting every check in slow end-to-end tests.
- - Ignoring loading and error states.
- - Assuming a React refresh bug is a backend bug without checking.
Try it yourself
Pick a screen from an app you use (for example a food order page). Split it into 4-6 components and list three test ideas for each.
Write your answer on paper or in a sheet first, then compare.
Interview questions
How to answer like a confident QA engineer
- Q1
Why should a QA engineer understand how React renders?
Model answer
Because many UI bugs come from rendering behaviour: data arriving after the first paint, state not resetting between screens, or a component redrawing with stale props. Knowing components, props and state lets me pick the right test layer, write tests that wait for the UI instead of sleeping, and describe bugs precisely, for example 'the cart badge does not update until refresh, so the Header is not reading the new cart state'.
- Q2
What are props and state?
Model answer
Props are inputs passed into a component by its parent and are read-only inside it. State is data the component owns and can change, such as form values; changing it triggers a re-render.
- Q3
What is a single-page application?
Model answer
An app that loads one HTML page and updates content with JavaScript as the user navigates, instead of requesting a new page from the server each time.
Knowledge check
+5 points
What makes a React component redraw?