Tdd

TDD draws two extreme reactions. The first: “I already write tests, so I do TDD.” The second: “writing tests first just reverses the effort without buying much.” Both miss what TDD really is. It is neither a coverage question nor a simple ordering trick. It is a design discipline that forces you to make an intention explicit before writing the code that satisfies it. This article opens a series on TDD. Before comparing the schools (Chicago, London, ATDD double loop, strict TDD), the shared trunk has to be laid down: the Red-Green-Refactor cycle, the practice of baby steps, and the FIRST properties that define a test that deserves the name. The next articles will build on this foundation to make the trade-offs tangible with concrete examples. ...

A test that has to isolate a function from its dependencies often ends up stacking patch() calls. Three dependencies, three nested with blocks. Five dependencies, a pyramid that pushes the useful code ten levels deep. The test becomes unreadable even though its intent is simple: verify a single behavior at a precise boundary. contextlib.ExitStack solves exactly this problem. It is a context manager that aggregates any number of others and closes them all cleanly on exit. Here is how I use it to keep a test focused on its boundary, with a concrete example on authentication. ...

This blog is first and foremost a place to share: discoveries, thoughts, things that have been useful to me and might be useful to others. Python, Django, Architecture and best practices: the heart of this blog The heart of the blog is Python development, and more specifically the frameworks that shape my daily work: Django, FastAPI and Flask. Each has its strengths, its use cases, its pitfalls. We’ll dig into all of them. ...