X

Invoice Test Coverage

The invoice test suite lives in apps/dashboard/__tests__/invoices and exercises the behaviours that power drafting, numbering, validating, and persisting invoices in the dashboard. Every file targets a specific workflow so failures quickly identify the broken capability.

Suites

• custom-fields.test.ts: guards JSON parsing, array CRUD, validation, and UUID v4 generation for the custom metadata attached to an invoice. These specs ensure we never write malformed metadata back to Supabase.
• generate-invoice-number.test.ts: verifies generateInvoiceNumber from @/lib/actions/invoice. The suite covers default prefixes, year formatting modes (hide, show, short), starting numbers, duplicate detection, and resilience when the fetch endpoints error.
• invoice-calculations.test.ts: checks the amount calculator that totals line items, taxes, discounts, and payments. Edge-case scenarios (tax exemptions, reverse charge, partial payments) prevent regressions in financial outputs.
• invoice-store-operations.test.ts: enforces the mutation contract of @/lib/zustand/useInvoiceStore. It validates optimistic line-item handling, pending update tracking, removal semantics, and store reset flows.
• invoice-validation.test.ts: validates schema-level guards to confirm we refuse to persist invoices lacking required fields, invalid dates, or broken totals.

Running the suite

Run everything:

pnpm vitest run apps/dashboard/__tests__/invoices
```typescript

Run a single file while iterating (for example, invoice numbering):

```bash
pnpm vitest run apps/dashboard/__tests__/invoices/generate-invoice-number.test.ts
```typescript

### Test data & mocks

- All API calls are routed through the data action helpers and mocked with
  `vi.mock("@/lib/actions/data")`, so no network traffic leaves the runner.
- `@/config` is also replaced to keep API base URLs deterministic.
- UUID generation relies on `crypto.randomUUID`; Node 18+ provides this out of
  the box. When backfilling fixtures locally, prefer `randomUUID()` for parity.

### When adding tests

- Import shared helpers directly from `@/lib/...` using the root-level `vitest.config.ts` alias.
- Stub network traffic via the standardized fetch/update wrappers from the
  workspace rules so behaviour matches production calls.
- Keep new cases focused—each file has a single responsibility so failures
  map to the workflow that needs attention.