Testing Web Applications: A Strategy That Catches Real Bugs

Effective web application testing requires a purposeful split of efforts. Prioritize many fast unit tests for logic, fewer integration tests that interact with real databases, and a select few end-to-end browser tests on revenue paths like signup and checkout. Execute the speedy tests on each pull request, while reserving the slower ones for after they pass successfully.

Metrics such as coverage percentage and test count should not be vanity measures; rather, focus on whether the suite can catch bugs that might otherwise reach production, runs swiftly enough so developers do not ignore it, and remains reliable enough that a failure signals a genuine issue.

Upon auditing various teams, three common problems emerge: 90% coverage but production still encounters issues, no tests resulting in terrifying deploys, or thousands of tests that run for 45 minutes and often become flaky randomly. These scenarios all stem from a lack of a well-defined testing strategy.

The testing pyramid offers guidance in determining the optimal distribution of test types. At the top, there are end-to-end (E2E) tests, which are few in number, relatively slow, but crucial for testing full user workflows. Below that, integration tests account for a medium count, verifying system boundaries by testing components' correct interaction (e.g., API handlers with databases, service layers handling edge cases, and auth middleware integration).

Finally, unit tests dominate the base of the pyramid, being many in number, running swiftly (milliseconds each), and focusing on testing logic in isolation. While unit tests verify individual functions and components, they do not confirm whether those pieces function harmoniously together.

Node.js and browser unit testing are streamlined with Vitest, the modern standard. It outperforms Jest, supports native ECMAScript modules, and employs the same API. A well-structured unit test validates the function's contract: valid inputs generate expected outputs, invalid inputs trigger appropriate errors, and edge cases are addressed appropriately.

For instance, consider a pricing calculator with its test suite in `src/utils/pricing.test.ts`:

```javascript

import { describe, it, expect } from 'vitest';

import { calculateDiscount } from './pricing';

describe('calculateDiscount', () => {

it('applies percentage discount correctly', () => {

expect(calculateDiscount(100, 20)).toBe(80);

expect(calculateDiscount(99.99, 10)).toBe(89.99);

});

it('caps discount at maxDiscount when specified', () => {

// 30% of $100 = $30, but maxDiscount is $20

expect(calculateDiscount(100, 30, 20)).toBe(80);

});

it('throws for discount out of range', () => {

expect(() => calculateDiscount(100, -5)).toThrow(RangeError);

expect(() => calculateDiscount(100, 101)).toThrow(RangeError);

});

it('handles edge cases', () => {

expect(calculateDiscount(100, 0)).toBe(100); // 0% discount

expect(calculateDiscount(100, 100)).toBe(0); // 100% discount

expect(calculateDiscount(0, 50)).toBe(0); // Zero price

});

});

```

When working with external dependencies like email services, employ Vitest's `vi.mock()` to verify that the code interacts with the service correctly without actually dispatching emails. Ensure the function passes the correct parameters and that errors are appropriately propagated.

Integration testing with real infrastructure necessitates the use of genuine databases and services instead of mocks. Mocking your database in integration tests undermines their purpose, as you need to ensure that the queries actually function correctly. Establish a dedicated test database, maintain its migrations, and cleanse it between test runs. Configure Vitest to run database tests serially (not in parallel) to prevent conflicts.

To streamline the setup of a disposable Postgres database, consult the provided Docker guide for web developers. This guide encompasses a reusable compose file, including a health check that prevents Vitest from racing the database upon startup. Within the test setup file, ensure tables are truncated in a dependency order between tests, thus initializing each test with a pristine state. Utilize factories to generate realistic test data with sensible defaults.