En el desarrollo de software, una parte del aseguramiento de la calidad está dada por la ejecución de pruebas que verifiquen que nuestro código hace lo que debe hacer.

Estás pruebas pueden ser automatizadas de distintas formas, con distintas técnicas. Sin embargo, hay que ser cuidadoso cuando empleamos una en particular, los Mocks.

Los Mocks son, en el mejor de los casos, una distracción y en el peor proporcionan una falsa confianza.

¿Que es el Mocking?

Es normal que los desarrolladores de software utilicemos mocks para simular el comportamiento de nuestro código, en especial, cuando se realizan llamadas que involucran otros servicios utilizando la red, como por ejemplo el acceso a una base de datos.

Esto facilita ejecutar pruebas unitarias que serán:

• Rápidas porque no necesitan depender de servicios adicionales
• Estables porque evitan problemas de disponibilidad

Entonces, significa que los Mocks se utilizan para el código que tiene efectos secundarios (side-effects), es decir código que modifica algo fuera de su contexto. De esta forma, podemos clasificar las funciones como:

• Puras: una función sin efectos secundarios
• Impuras: una función que contiene uno o mas efectos secundarios

Los problemas con los Mocks

Los Mocks no son equivalentes a las integraciones que reemplazan

Si un mock simula a un cliente de base de datos, no se ha probado la integración con el cliente de base de datos real. Esto se traduce en que tu código puede funcionar con el Mock, pero aún deberás realizar pruebas de integración para asegurarte que funcione sin mocks

La equivalencia de funcionalidad no es real

Si haces rápidamente un mock, lo más probable es que no devolverá datos útiles. Cuanto más tiempo dediques a mejorar el mock, más útiles serán los datos. Sin embargo, el mock nunca tendrá una equivalencia de funcionalidad exacta.

Los Mocks que no se utilizan son una pérdida de tiempo y esfuerzo

Si tu creas un mock para simular al cliente de base de datos y no lo utilizas, entonces no tienen sentido crear dicho mock. Esto es muy común que suceda en código que es utilizado para inicializar algún tipo de conexión válida.

Pero entonces: ¿Cómo reemplazamos a los mocks en nuestras pruebas?

Los mocks se utilizan para proporcionarnos velocidad y estabilidad en nuestras pruebas, pero podemos obtener el mismo resultado de otras formas.

¡Refactoriza tu código!

Podemos reemplazar la necesidad de mocks separando las funciones puras de las impuras. Las funciones puras pueden probarse unitariamente sin necesidad de mocks y las funciones impuras solo deberían probarse por pruebas de integración.

¡Mejora tus automatizaciones!

Al automatizar los artefactos del software, el despliegue y las pruebas, podemos concentrar nuestros esfuerzos en pruebas de integración más rápidas en lugar de depender unicamente de pruebas unitarias. Esto facilita la entrega continua y reduce el impacto del tan conocido «en mi local funciona»

En resumen…

Los mocks son una solución de corto plazo y un problema a largo plazo. Si deseas entregar sofware más rápido, debes dedicar menos tiempo a crear mocks y más tiempo a la refactorización y a la automatización.