write-tests-frontend

Writing Frontend Component Tests

Thesis: Frontend tests verify behavior through props, callbacks, and rendered content — not rendering existence alone. Know jsdom's limits.

Before writing tests for a module, read docs/modules/{module}/spec.md for the Critical Test Scenarios section — it's a verified test plan.

Always Test Error Paths

Don't just test happy paths. Every service method should have tests for:

• Permission denied — wrong user type, non-owner, non-member → expect FORBIDDEN
• Invalid status — operation on wrong-status entity → expect BAD_REQUEST
• Not found — non-existent ID → expect NOT_FOUND
• Duplicate/conflict — re-creating existing entity → expect CONFLICT

These are the bugs that slip through manual testing and break in production.

This section is intentionally duplicated in write-tests.mdc and write-tests-frontend.mdc. If updated, change both.

Component Unit Tests (SolidJS)

Use @solidjs/testing-library for component-level tests. Test the public API: renders, accepts props, fires events.

import { afterEach } from "vitest";
import { cleanup, render, screen, fireEvent } from "@solidjs/testing-library";
import { Button } from "./Button";

afterEach(cleanup);

test("calls onClick", async () => {
  const handler = vi.fn();
  render(() => <Button onClick={handler}>Click</Button>);
  await fireEvent.click(screen.getByText("Click"));
  expect(handler).toHaveBeenCalledTimes(1);
});

Place test files next to the component: Button.test.tsx alongside Button.tsx. Vitest discovers src/**/*.test.{ts,tsx} automatically.

Important: vitest.config.ts must have resolve.conditions: ["development", "browser"] to prevent Solid from resolving server-side bundles in jsdom.

Always call afterEach(cleanup) in *.test.tsx files that use @solidjs/testing-library. Without cleanup, previous renders can leak Solid computations into the next test and emit "computations created outside a root" warnings.