write-specs-frontend

Write specs for a slice's React/TypeScript surface — view models, helpers, and narrow component behavior. Full conventions live in .ai/rules/frontend-testing.md; this skill is the application frontend peer to write-specs (backend). For framework @cratis/* package specs (the given() helper), use cratis-specs-typescript instead.

Placement & naming

Specs live next to the unit, snake_case so the path reads as a sentence:

<Slice>/
  <Subject>.ts
  for_<Subject>/
    when_<context>/
      and_<extra_context>.ts

describe('when ...') names the scenario, not the class; it('should ...') uses spaces; each it asserts one observable outcome.

Stack

Vitest (describe/beforeEach/it) · SinonJS (sinon.stub() / createStubInstance) · Chai .should fluent — never expect().

What to cover

• View models (the primary target): state transitions, computed getters, filtering/sorting/selection, wizard steps, validation state, command-value derivation.
• Command orchestration outside CommandDialog: unauthorized / invalid / exception / success handling.
• Pure helpers: parsing, formatting, grouping, boundary cases.
• Component rendering only when markup, disabled state, or wrapper behavior is the point.

Don't spec: generated Cratis proxies, PrimeReact/framework internals, CSS pixel-perfection, snapshots, or trivial presentational pass-throughs.

View-model spec (default)

View models are plain classes constructible directly — no React hooks; no direct window/localStorage/timers/network (inject the abstraction); derived values are getters.

import { describe, beforeEach, it } from 'vitest';
import { CandidatesViewModel } from '../../CandidatesViewModel';

describe('when filtering by search text', () => {
    let viewModel: CandidatesViewModel;

    beforeEach(() => {
        viewModel = new CandidatesViewModel();
        viewModel.setSearch('senior');
    });

    it('should keep only matching candidates', () =>
        viewModel.filteredItems.should.have.lengthOf(1));
});