Testing

Un test para place_order necesita una pasarela de pago, un cliente de SMS y una calculadora de impuestos. Conecta las versiones reales y cada ejecución del test cobra una tarjeta y manda un SMS a un número real. Un test unitario tiene que correr en milisegundos y sin red, así que las tres dependencias hay que sustituirlas por otra cosa. Ese “otra cosa” llega en cinco variantes. Cada una resuelve un problema distinto, y tratarlas como intercambiables explica por qué las discusiones de “pon un mock y ya” en code review no llegan a ningún lado. ...

Un test escrito después del código tiende a comprobar lo que el código hace, no lo que debía hacer. El desarrollo guiado por pruebas (TDD) resuelve esto invirtiendo el orden: escribes el test, lo ves fallar, y luego escribes el código mínimo que lo hace pasar. El test existe antes que el código que examina, así que no puede limitarse a confirmar en silencio lo que ese código termine devolviendo. Kent Beck formalizó este ciclo como red, green, refactor en su libro de 2002 Test-Driven Development: By Example. El nombre se quedó. ...

Una función puede tener el 100% de cobertura de pruebas unitarias y la página que la llama puede seguir devolviendo un 500 en producción. No es una contradicción. Las pruebas unitarias, de integración y end-to-end comprueban cosas distintas, y una suite cargada en una y floja en otra tiene un hueco específico y predecible. Qué comprueban las pruebas unitarias, de integración y end-to-end Toma una funcionalidad de registro: una función valida la entrada, escribe una fila en una base de datos y envía un correo de bienvenida. Tres pruebas pueden cubrirla, y cada una responde una pregunta distinta. ...