> I use mocks to arrange state A without going through all the business rules involved in creating state A.
An issue is that unless the types are really nailed down you can create easily create invalid or incomplete states, or create a state which is correct at one point then becomes invalid / incomplete at an other.
> Earlier tests have already verified all routes to State A
Unless they also assert the complete state at that point and that assertion is tied into the next state[0] then what they've verified is a series of steps.
Seems risky to assume it matches what an unrelated tests starts with, unless you've implemented state restoration, at which point you'd have to add cross-test dependencies such that the result of the tests validating section A can be saved and restore for every test needing a state A to test section B.
[0] that is, ∅ -> A tests end with an identity check for state A (that the system entire has no more and no less than expected) and that A -> B tests start with one, right after they've generated their fake state
An issue is that unless the types are really nailed down you can create easily create invalid or incomplete states, or create a state which is correct at one point then becomes invalid / incomplete at an other.
> Earlier tests have already verified all routes to State A
Unless they also assert the complete state at that point and that assertion is tied into the next state[0] then what they've verified is a series of steps.
Seems risky to assume it matches what an unrelated tests starts with, unless you've implemented state restoration, at which point you'd have to add cross-test dependencies such that the result of the tests validating section A can be saved and restore for every test needing a state A to test section B.
[0] that is, ∅ -> A tests end with an identity check for state A (that the system entire has no more and no less than expected) and that A -> B tests start with one, right after they've generated their fake state