Test end-to-end

Un test end-to-end entra por la misma puerta que usaría un cliente real, una petición HTTP, y comprueba lo que sale al otro lado, la respuesta. No se mockea nada por el camino: ni el routing, ni el handler, ni la base de datos. Si algo de eso está roto, el test falla, sin importar qué función interna sea la culpable.

Eso es distinto de un test unitario, que llama directamente a una función y comprueba lo que devuelve, con todo lo que esa función necesita simulado o sustituido. Un test unitario puede estar en verde mientras el sistema al que pertenece está completamente roto, si el cableado entre piezas está mal, o si dos funciones pasan cada una su propio test pero no se ponen de acuerdo sobre qué se pasan entre ellas.

El coste es el precio a pagar: un test end-to-end es más lento, porque está ejercitando un servidor real y una base de datos real en lugar de una sola llamada a función en memoria. Por eso mismo no es la primera herramienta a la que recurrir en todas partes, solo para los endpoints donde la corrección depende de verdad de que toda la cadena funcione junta, no de una función aislada.