cratis-application-react-specifications

Cratis application React specifications

Frontend specifications are specifications, not tests. The for_ / when_ / and_ shape is deliberately the same BDD language as the backend, so one subject, one context, clear setup, and small assertions read as sentences.

This is the application frontend peer of cratis-application-slice-specifications for backend pipeline scenarios. Framework package (@cratis/*) specifications use cratis-specifications-typescript and the repository's conventions instead.

Stack

• Vitest for the runner, with Mocha-style describe / beforeEach / it.
• Sinon for stubs and fakes (sinon.stub(), sinon.createStubInstance()).
• Chai with the .should fluent interface — never expect(). result.should.equal(expected) reads as a sentence.

Placement and naming

Specifications live next to the unit they specify, in snake_case so the path reads as a scenario sentence:

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

Shape	Use for
for_<Subject>/when_<context>/and_<extra>.ts	the default — view models, branching helpers, component specs
for_<Subject>/when_<context>.ts	a tiny pure helper with no useful extra context

describe('when ...') names the scenario, not the class. it('should ...') uses spaces, not underscores, and asserts one observable outcome. Do not add .test.ts or .spec.ts files unless the project's configuration changes deliberately.

What to specify

Behavior that can regress without TypeScript catching it:

• View models — the primary target. State transitions, computed getters, filtering, sorting, selection, wizard steps, validation state, and command-value derivation.
• Command orchestration outside a command dialog — the unauthorized, invalid, exception, and success branches.
• Pure helpers — parsing, formatting, grouping, boundary cases.
• Component rendering only when the markup, a disabled state, or wrapper behavior is genuinely the point.