In '''test-driven development''', <ref name="TTD">{{Cite web|url=http://www.dotcominfoway.com/articles_tdd_improve_the_quality_of_applications.asp
|title=Improving the Quality of Applications Using Test Driven Development
{{Cite web|url=http://www.dotcominfoway.com/articles_tdd_improve_the_quality_of_applications.asp|title=Improving the Quality of Applications Using Test Driven Development|accessdate=26 February|accessyear=2008</ref> each new feature begins with writing a test. This test must inevitably fail because it is written before the feature has been implemented. In order to write a test, the developer must understand the specification and the requirements of the feature clearly. This may be accomplished through [[use case]]s and [[user story|user stories]] to cover the requirements and exception conditions. This could also imply an invariant, or modification of an existing test. This is a differentiating feature of test-driven development versus writing unit tests ''after'' the code is written: it makes you focus on the requirements ''before'' writing the code, a subtle but important difference.
