Editing Test-driven development (section)

=== Practices to avoid, or "anti-patterns" ===
{{see also|Anti-pattern}}
* Having test cases depend on system state manipulated from previously executed test cases (i.e., you should always start a unit test from a known and pre-configured state).
* Dependencies between test cases.  A test suite where test cases are dependent upon each other is brittle and complex. Execution order should not be presumed. Basic refactoring of the initial test cases or structure of the UUT causes a spiral of increasingly pervasive impacts in associated tests.
* Interdependent tests.  Interdependent tests can cause cascading false negatives. A failure in an early test case breaks a later test case even if no actual fault exists in the UUT, increasing defect analysis and debug efforts.
* Testing precise execution, behavior, timing or performance.
* Building "all-knowing oracles".  An oracle that inspects more than necessary is more expensive and brittle over time. This very common error is dangerous because it causes a subtle but pervasive time sink across the complex project.<ref name="pathfindersolns.com">{{YouTube| id=0BWSms3J40Y| title=Test-Driven Development (TDD) for Complex Systems Introduction}} by Pathfinder Solutions</ref>{{Clarify|reason=needs better explanation, what is an all-knowing oracle? needs better tone, more factual|date=February 2022}}
* Testing implementation details.
* Slow running tests.