TDD - the why, the how and the when not
summary
Argues that TDD gives concrete control: it catches Python’s dynamic-typing errors, makes refactoring safe, and forces clearer test names; recommends pytest and continuous builds so the team sees failures; warns bad tests “cost interest,” hard-to-test areas (async, framework mixins, evolving abstract subclasses) may be skipped, and architecture/process must fit TDD; suggests learn on a small project like tic-tac-toe, use CI and aim for disciplined suites rather than chasing 100% coverage as a vanity metric.
AI-written summary · about
