CsCheck

Use CsCheck to explore inputs and action sequences; keep the application's contract visible in the test. Let the library generate, shrink, print, and replay counterexamples. Start with the smallest test that can falsify the claim, rather than building a testing framework around CsCheck.

Choose the test shape

What needs checking	Start with	Read when needed
A function, round trip, algebraic law, or data transformation	Gen + Sample	Properties and generators
An implementation with a simpler reference representation	SampleModelBased / SampleModelBasedAsync	Stateful and async tests
A protocol or lifecycle with explicit state, guards, and requirements	Spec.From, then Exhaustive and Conform	Executable specifications
Async resources or expectations that must incorporate observed outcomes	Generated command arrays + SampleAsync, with cleanup inside each case	Stateful and async tests
A failing property, seed replay, or a before/after bug demonstration	Native sampling controls and a concrete regression	Failure discovery and replay

Read only the references needed for the task. These examples use xUnit, but CsCheck itself is test-framework independent. Preserve the project's existing framework and package-management conventions.

Establish the contract first

Identify an observable requirement and a plausible wrong result it would reject. Separate generated inputs, expected behavior, and actual observations. A model may consume observations, but must validate them against prior expectations before accepting them as new state. Do not use the implementation's answer to manufacture its expected answer.