Editing Test-driven development (section)

== Best practices ==

=== Test structure ===
Effective layout of a test case ensures all required actions are completed, improves the readability of the test case, and smooths the flow of execution. Consistent structure helps in building a self-documenting test case. A commonly applied structure for test cases has (1) setup, (2) execution, (3) validation, and (4) cleanup.
* Setup: Put the Unit Under Test (UUT) or the overall test system in the state needed to run the test.
* Execution: Trigger/drive the UUT to perform the target behavior and capture all output, such as return values and output parameters. This step is usually very simple.
* Validation: Ensure the results of the test are correct. These results may include explicit outputs captured during execution or state changes in the UUT.
* Cleanup: Restore the UUT or the overall test system to the pre-test state. This restoration permits another test to execute immediately after this one. In some cases, in order to preserve the information for possible test failure analysis, the cleanup should be starting the test just before the test's setup run. <ref name="Pathfinder Solutions" />

=== Individual best practices ===

Some best practices that an individual could follow would be to separate common set-up and tear-down logic into test support services utilized by the appropriate test cases, to keep each [[test oracle]] focused on only the results necessary to validate its test, and to design time-related tests to allow tolerance for execution in non-real time operating systems. The common practice of allowing a 5-10 percent margin for late execution reduces the potential number of false negatives in test execution. It is also suggested to treat test code with the same respect as production code. Test code must work correctly for both positive and negative cases, last a long time, and be readable and maintainable. Teams can get together and review tests and test practices to share effective techniques and catch bad habits.<ref name="pathfindersolns.com" />

=== 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.