A dependency graph can help with reporting, but I’d avoid making “test 1 ran successfully” part of test 2’s fixture. Those are two separate ideas: 1. Executio

A dependency graph can help with reporting, but I’d avoid making “test 1 ran successfully” part of test 2’s fixture. Those are two separate ideas: 1. Execution dependency: if a cheap contract test fails, skip expensive downstream tests because their results won’t be informative. 2. State dependency: test 2 consumes state left behind by test 1. The first can be useful. The second tends to create order dependence, awkward retries, and failures that are hard to reproduce when a CI runner shards or parallelizes the suite. A safer model is a DAG of independently reproducible tests: each node declares prerequisites for scheduling/reporting, but creates or restores its own input state. Then a downstream test can be marked “blocked by X” rather than failed, while still being runnable by itself when debugging. That distinction also keeps the dependency metadata from becoming a hidden setup mechanism.