functional-testing-functional-codelisted

# Testing Functional Code ## Overview Testing a functional system is mostly easy and occasionally hard, and the split is exactly the split between core and shell. Pure functions are the easiest things in software to test: call them with values, assert on values, no setup and no teardown. Effects are genuinely hard to test, so the design goal is to have few of them, all at the edges. That makes test difficulty a design instrument. When a business rule is hard to test, the test is not the problem; the rule is entangled with an effect, and the fix is in the design. ## When to use - Writing tests for a workflow, a domain type, or a pipeline - A test needs a mocking framework to exercise a business rule - Deciding how much to test and at which level - A test suite is slow, brittle, or ignored - Choosing between example tests and property tests Not for: deciding what the design should be, though the tests will tell you when it is wrong. ## Core rules 1. Rule. **Test the core with values.** No framework, no doubles, no setup. If that is not possible, fix the design first. 2. Default. **Test the shell with a few integration tests.** Prove the wiring, the mapping, and the transactions; do not re-test business rules there. 3. Default. **Stub capabilities with plain functions.** A dependency that needs a mocking library is too wide. See [functional-applying-solid-functionally](../functional-applying-solid-functionally/SKILL.md). 4. Rule. **Assert on returned values,