Automated Testing Services

• Unit Tests: Individual functions, classes, and modules in isolation pure business logic with all dependencies mocked. Fast (milliseconds per test), cheap to write, cheap to run. The bulk of the test suite. Tools: Jest (Node.js), pytest (Python), Vitest (Vite/React).
• Integration Tests: Multiple components working together API endpoint + database, service + cache, authentication + authorisation. Medium speed (seconds per test Testcontainers starts real database). More valuable than unit tests for catching real bugs. Tools: Jest + Supertest (Node.js API), pytest + httpx (Python), Testcontainers (real PostgreSQL + Redis).
• Component Tests: React components rendering and responding to user interactions rendered in a virtual DOM. Fast (milliseconds). Verify component behaviour from the user's perspective not implementation details. Tools: React Testing Library + Jest/Vitest, user-event for interaction simulation.
• E2E Tests: Complete user workflows in a real browser login, complete a purchase, create a record. Slow (seconds to minutes per test). Most valuable for critical paths, most expensive to maintain. Keep the E2E suite small and focused. Tools: Playwright (primary cross-browser, fast, reliable), Cypress (alternative).
• Contract Tests: API contracts between services verify that a service's API response matches what its consumers expect. Fast. Prevents integration failures when a service changes its API without updating consumers. Tools: Pact (consumer-driven contract testing), OpenAPI schema validation.

Mocking the database in integration tests produces tests that pass even when the application has bugs specifically bugs that would only manifest with a real database: SQL syntax errors (a mocked database accepts any SQL string), schema migration state (a mocked database is not aware of your actual schema a test can pass even if the column it queries does not exist), transaction behaviour (mocked databases cannot simulate database-level constraint violations, transaction rollbacks, or concurrent writes), and ORM behaviour differences (some ORM queries produce different SQL in different environments Testcontainers uses the same database engine as production, ensuring the same SQL is executed). Testcontainers starts a real PostgreSQL Docker container for the test run the exact same database engine, configuration, and schema as production. Tests that pass with Testcontainers have a much higher probability of passing in production.

React Testing Library (RTL) is a testing utility that renders React components and provides queries for finding elements in the way a user would find them (by role, label, text), not in the way a developer would find them (by component name, props, or state). The design principle: test the behaviour a user would observe, not the implementation details of the component. RTL encourages: querying by accessible role (`getByRole('button', {name: 'Submit'})`), testing user interactions (`await userEvent.click(button)`), and asserting on visible outcomes (text appears, element is visible, navigation occurs) not on React state, prop values, or component hierarchy. Enzyme (the previous dominant React testing library) encouraged testing implementation details component internal state, lifecycle methods, direct prop manipulation. Enzyme tests break when components are refactored (even if user-visible behaviour is unchanged). RTL tests survive refactors because they test what the user sees, not how the code works. Enzyme is deprecated as of React 18; RTL is the current standard.