The initial state of the model, before any actions are performed.

Generate a random action given the current state. The generated action should be appropriate for the current state.

Precondition that must hold before an action can be executed. Return False to indicate that an action is not valid in the current state. Default: all actions are always valid.

Perform the action on the real blockchain (mockchain). This should execute the actual transaction(s) that implement the action. The current model state is provided to allow access to tracked blockchain state. The returned state should reflect the expected effect of the action on the contract state.

Validate that the blockchain state matches the model state. Default: no validation (always succeeds).

Called after each successful action to wrap the enclosing QuickCheck property. This hook runs only after perform and validate succeed. Use it for property-level checks, labels, and counterexamples that should be attached to valid state transitions. Default: no additional checks.

Whether to discard (skip) test cases where the invalid action fails due to a user-level error (e.g., off-chain balancing failure) rather than an on-chain validator rejection during negative testing.

When True, negative tests that throw user exceptions are discarded (via QuickCheck's discard), so only on-chain rejections count as successful negative tests.

When False (the default), user exceptions also cause the test case to be discarded — meaning both off-chain and on-chain failures are treated the same way.

Override this in your TestingInterface instance if you need finer control over which failure modes are accepted in negative testing.

Threat models to run against the transactions. Each threat model will be evaluated against the transaction generated by a succesful test run with the UTxO state captured before each transaction executed. Default: the list of all threat models that don't take parameters.

Threat models that are expected to find vulnerabilities. These are run like threatModels but with inverted pass/fail semantics:

• OK when a vulnerability IS detected
• FAIL when a vulnerability is NOT detected

Output is quiet — no verbose transaction dumps. Default: empty, backward compatible.

A generator for values of the given type.

It is worth spending time thinking about what sort of test data you want - good generators are often the difference between finding bugs and not finding them. You can use sample, label and classify to check the quality of your test data.

There is no generic arbitrary implementation included because we don't know how to make a high-quality one. If you want one, consider using the testing-feat or generic-random packages.

The QuickCheck manual goes into detail on how to write good generators. Make sure to look at it, especially if your type is recursive!

Produces a (possibly) empty list of all the possible immediate shrinks of the given value.

The default implementation returns the empty list, so will not try to shrink the value. If your data type has no special invariants, you can enable shrinking by defining shrink = genericShrink, but by customising the behaviour of shrink you can often get simpler counterexamples.

Most implementations of shrink should try at least three things:

1. Shrink a term to any of its immediate subterms. You can use subterms to do this.
2. Recursively apply shrink to all immediate subterms. You can use recursivelyShrink to do this.
3. Type-specific shrinkings such as replacing a constructor by a simpler constructor.

For example, suppose we have the following implementation of binary trees:

data Tree a = Nil | Branch a (Tree a) (Tree a)

We can then define shrink as follows:

shrink Nil = []
shrink (Branch x l r) =
  -- shrink Branch to Nil
  [Nil] ++
  -- shrink to subterms
  [l, r] ++
  -- recursively shrink subterms
  [Branch x' l' r' | (x', l', r') <- shrink (x, l, r)]

There are a couple of subtleties here:

• QuickCheck tries the shrinking candidates in the order they appear in the list, so we put more aggressive shrinking steps (such as replacing the whole tree by Nil) before smaller ones (such as recursively shrinking the subtrees).
• It is tempting to write the last line as [Branch x' l' r' | x' <- shrink x, l' <- shrink l, r' <- shrink r] but this is the wrong thing! It will force QuickCheck to shrink x, l and r in tandem, and shrinking will stop once one of the three is fully shrunk.

There is a fair bit of boilerplate in the code above. We can avoid it with the help of some generic functions. The function genericShrink tries shrinking a term to all of its subterms and, failing that, recursively shrinks the subterms. Using it, we can define shrink as:

shrink x = shrinkToNil x ++ genericShrink x
  where
    shrinkToNil Nil = []
    shrinkToNil (Branch _ l r) = [Nil]

genericShrink is a combination of subterms, which shrinks a term to any of its subterms, and recursivelyShrink, which shrinks all subterms of a term. These may be useful if you need a bit more control over shrinking than genericShrink gives you.

A final gotcha: we cannot define shrink as simply shrink x = Nil:genericShrink x as this shrinks Nil to Nil, and shrinking will go into an infinite loop.

If all this leaves you bewildered, you might try shrink = genericShrink to begin with, after deriving Generic for your type. However, if your data type has any special invariants, you will need to check that genericShrink can't break those invariants.