Mocking

¿Qué es el mocking?

El mocking reemplaza una dependencia real por una falsa para que una prueba pueda correr de forma aislada. Cuando el código que compruebas llama a un proveedor de pagos, a una base de datos o a una API de terceros, no quieres que la prueba cobre de verdad una tarjeta ni dependa de que un servidor esté en pie. Un mock ocupa el lugar de esa dependencia, devuelve la respuesta que le indicas y te deja verificar el código en cuestión sin arrastrar el mundo entero a la prueba.

El vocabulario alrededor es preciso, y las distinciones importan. Un stub devuelve una respuesta enlatada para que el código tenga algo con lo que trabajar. Un mock va más allá y registra cómo fue llamado, así la prueba puede afirmar que una función se disparó con los argumentos correctos el número correcto de veces. Un fake es una implementación ligera y funcional, como una base de datos en memoria que se comporta como la real pero solo vive durante la prueba. Hacer mocking cuando un checkout llama a una API de pagos significa que la prueba puede simular un cobro con éxito, una tarjeta rechazada y un timeout en tres ejecuciones separadas, ninguna de las cuales toca dinero real.

La concesión es el realismo. Un mock solo se comporta como tú le dijiste, así que si tu supuesto sobre la dependencia real está equivocado, la prueba pasa mientras producción falla. Por eso los mocks pertenecen a las pruebas unitarias, donde el aislamiento es el objetivo, y las pruebas de integración siguen ejercitando las conexiones reales para confirmar que los supuestos se sostienen.

El mocking en Dallonses

Hacemos mocking para que las pruebas sean rápidas y deterministas, y sabemos dónde parar. Las pruebas unitarias mockean el mundo externo para correr en milisegundos y no fallar nunca por un hipo de red. La capa de integración mantiene las conexiones reales, porque ese es el único sitio donde un supuesto equivocado sobre una API de terceros se atrapa de verdad.

El riesgo que vigilamos es una suite que está en verde porque solo prueba los mocks. Nuestro testing automatizado mantiene los mocks honestos atándolos a los contratos reales y actualizándolos cuando una API cambia, de modo que una prueba que pasa significa código que funciona y no una ficción cómoda. Documentamos qué se ha falseado y por qué, para que el equipo que herede la suite sepa exactamente qué prueba y qué no.

¿Pruebas lentas, inestables o tocando servicios reales que no deberían? Apretémoslas.

Hablemos de QA