## Metadata * URL: [https://github.com/testdouble/contributing-tests/wiki/Detroit-school-TDD](https://github.com/testdouble/contributing-tests/wiki/Detroit-school-TDD) * Author: [[testdouble|Testdouble]] ## Highlights * Some folks call it "Classical", "Traditional", or merely "TDD" * [[Classical TDD (or Detroit-school)|Classical Tdd Or Detroit School]] * emphasizing refactoring as a task to be completed after arriving at a working implementation has so often become a point of contention for teams using TDD that it warrants valid criticism of the methodology. Typically, if a team is under pressure * Rules similar to the ones published by Michael Feathers in 2005 are common * Practitioners of Detroit-school TDD often favor "bottom-up" development, in which smaller units are developed first (in anticipation of their being needed by the larger system) * This tendency emerges because "outside-in" development would result in uncomfortably large units of work. * A significant drawback of bottom-up development is the opportunity for waste, dead code, and rework to result: * it's fairly common that the subordinate components the developer predicts they will need won't actually be needed when it comes time to plug them into the public-facing unit