Testing, TypeScript & Deployment
React Testing with React Testing Library
React Testing Library tests components the way a user experiences them: it finds elements by visible text, label and role rather than by class name, and asserts on what appears on screen rather than on internal state.
What is Testing with React Testing Library in React?
React Testing Library tests components the way a user experiences them: it finds elements by visible text, label and role rather than by class name, and asserts on what appears on screen rather than on internal state.
Why Testing with React Testing Library matters
Tests written against implementation details break on every refactor. Tests written against visible behaviour keep passing while the code changes underneath, which is what makes them worth maintaining.
Testing with React Testing Library example
import { render, screen } from '@testing-library/react';
import userEvent from '@testing-library/user-event';
test('shows an error for an invalid email', async () => {
render(<SignupForm />);
await userEvent.type(screen.getByLabelText(/email/i), 'not-an-email');
await userEvent.click(screen.getByRole('button', { name: /continue/i }));
expect(await screen.findByText(/enter a valid email/i)).toBeInTheDocument();
});How this works
getByRole and getByLabelText mirror how assistive technology finds elements, so a passing test is also weak evidence that the form is accessible.
Key points to remember
- Query priority: getByRole, then getByLabelText, then getByText; use test ids last.
- findBy* returns a promise and waits — use it for anything asynchronous.
- Prefer userEvent over fireEvent; it simulates real interaction sequences.
- Vitest is the usual runner in Vite projects; Jest elsewhere.
Common mistakes with Testing with React Testing Library
- Asserting on state or props instead of rendered output.
- Using getBy for an element that appears asynchronously — it throws instead of waiting.
React Testing with React Testing Library— Interview Questions & FAQs
Should I test implementation details?+
No. Test what the user sees and does. Assertions on internal state break on every refactor while telling you nothing about whether the feature works.
