Testing

El TDD provoca dos reacciones extremas. La primera: “ya escribo tests, entonces hago TDD”. La segunda: “escribir los tests antes solo invierte el esfuerzo sin ganar mucho”. Ambas pasan por alto lo que realmente es el TDD. No es una cuestión de cobertura ni una simple inversión de orden. Es una disciplina de diseño que obliga a explicitar una intención antes de escribir el código que la satisface. Este artículo abre una serie sobre TDD. Antes de comparar las escuelas (Chicago, Londres, ATDD doble bucle, TDD estricto), hay que asentar el tronco común: el ciclo Rojo-Verde-Refactor, la práctica de los baby steps y las propiedades FIRST que definen un test que merece ese nombre. Los artículos siguientes partirán de esta base para hacer los compromisos tangibles, con ejemplos concretos. ...

Un test que debe aislar una función de sus dependencias acaba a menudo apilando llamadas a patch(). Tres dependencias, tres with anidados. Cinco dependencias, una pirámide que empuja el código útil diez niveles de indentación. El test se vuelve ilegible aunque su intención sea simple: verificar un solo comportamiento en una frontera precisa. contextlib.ExitStack resuelve exactamente este problema. Es un gestor de contexto que agrega un número cualquiera de otros y los cierra todos de forma limpia al salir. Así es como lo uso para mantener un test centrado en su frontera, con un caso concreto sobre la autenticación. ...