# Mission: Spotting where property-based testing pays off

> **Draft** — written from the opening request. Correct me where I've guessed.

## Why
Martin mostly builds CRUD apps. The standard property-based testing (PBT) examples — reversing
lists, sorting, Roman numerals — don't map onto that work, so it's unclear when PBT is worth
reaching for. The goal is to be able to look at a piece of ordinary application code and say
whether a property exists, which kind it is, and whether it beats a few example-based tests.

## Success looks like
- Can name Wlaschin's seven property patterns and Hughes's five approaches, and map each onto
  something that exists in a CRUD codebase (serialisers, validators, permission checks, filters,
  pagination, migrations, sync, money).
- Given a function or endpoint, can say in one sentence which property it has — or that it has
  none worth testing — and justify that against the cost of writing a generator.
- Recognises the Goldstein et al. high-leverage signal: *"a really good abstraction with a
  complicated implementation"*, and knows the CRUD versions of it (an in-memory model of a
  repository, a reference query, an inverse operation).
- Can sketch a stateful (model-based) property for a CRUD resource: commands, a model, and the
  check that ties them together.

## Constraints
- Chosen first direction (2026-10-06): stateful / model-based testing of a CRUD resource.
- Recognition first, execution second: the immediate ask is practice at *identifying* situations.
- Examples in TypeScript with fast-check unless asked otherwise.
- One question at a time; no multiple choice.

## Out of scope
- Generator and shrinker internals.
- Fuzzing for security vulnerabilities.
- Formal verification and proof.