Guidelines

This document contains the guidelines used to make design and code choices when extending or maintaining ContractCase.

Values

User first: If misconfigurations happens, ContractCase will print helpful errors that assist the user in finding a solution
- Errors will say what's wrong at the start, followed by a longer explanation
Not magic: ContractCase prefers strict and fail-fast behaviour over "I guess you probably meant this". If there is a misconfiguration, and the user may have meant more than one thing, case will fail with with helpful errors.
One model: There's only one model for ContractCase. It's used in the contract file, to set contract tests, to extend with plugins, and to think about how tests work.

Don't build features inside the boundaries layer, as this is meant to be a thin wrapper / DSL around the core interface. This will avoid the problem of some features existing in some languages and not others.
All matchers are immutable. Don't edit the contents of a matcher, instead, if you need to change something inside a matcher, produce a new tree and call that instead.
The context is also immutable data (but may be replaced as you walk the matcher tree)

All matchers are only data, so they can be saved in the contract and passed around
Matchers are recursive. Each matcher that has children also accepts matchers.
Extensible: To implement a new matcher, you just implement the interface. See the Adding Matchers documentation
The only difference between test and verification is: Verification is multiple tests, while test is a single test. The input to a single verification is the same as the input to a single test.