Test-driven development is a coding practice wherein developers write unit tests that guide iterative software development (similar ideas are being discussed by data practitioners who promote data contracts). In this post, Hillel Wayne presents TDD as a useful technique when treated as a practice wherein developers “write tests before code in short feedback cycles” but criticizes strong, maximalist TDD (e.g. the red-green-refactor cycle) that focuses on minimality and treats TDD as a design process with no credible alternatives. He notes that TDD without other testing and verification techniques may not detect higher-level bugs that arise when correct components interact in unexpected ways. In addition, he suggests that the design process and approach to code organization prescribed by TDD may not be well suited to some applications and use cases that require more upfront thinking. Nonetheless, he concludes by listing the benefits of weak TDD and recommending that developers use TDD in a portfolio of methods.