La automatización de test es actualmente el gran objetivo y reto a los que se enfrentan todos los equipos de desarrollo, pero este paso es el final de un largo camino de testing. Las pruebas unitarias son fundamentales para asegurar la calidad del código. Dentro de estas pruebas, conceptos como mock y fake juegan un papel crucial al simular el comportamiento de dependencias externas o complejas. Pero, ¿sabes realmente qué diferencia a un mock de un fake? En este post explicaremos qué son, cuándo utilizarlos y cómo pueden ayudarte a escribir pruebas más eficientes y confiables.
Pirámide del Testing Ágil
Si no la conoces, la «Pirámide de Testing Ágil» es una metáfora donde podemos ver los diferentes tipos de test en bloques, y la proporción que debería tener respecto a los siguientes, como en la siguiente imagen, con el objetivo de dar la vuelta al enfoque clásico de test donde había muchas pruebas manuales y pocas automatizadas. Aquí el objetivo final es tener pruebas automatizadas end to end.
Vamos a empezar por el principio, fijémonos en la base, los tests unitarios. De sobra conocido, los test unitarios prueban componentes de código de forma aislada. Y es aquí donde nos encontramos un gran impedimento cuando empezamos a implementarlo. Si el código que voy a cubrir tiene una dependencia externa (por ejemplo llamada a un servicio externo de autenticación, un acceso a base de datos o la lectura de un fichero externo) ¿cómo puedo emular el resultado de esta dependencia? ¿Cómo puedo asegurar la calidad del dato de mi test si quiero probar de forma aislada?
Es ahí donde entran en juego el Mock testing y el Fake testing, dos elementos que eliminan la necesidad de estas dependencias en la ejecución de nuestros tests. Estos elementos están englobados dentro de la categoría de test dobles, ya que se genera un «doble» para sustituir esa dependencia.
Mock testing
Una de las principales técnicas para eliminar estas dependencias es hacer mocks. Un mock no deja de ser una implementación de una interfaz que necesitamos en nuestro test con unos valores específicos y preconfigurados. Es decir, un mock se utiliza para simular los datos necesarios de un objeto para un escenario en concreto, así podemos probar un comportamiento funcional específico. Esta es una de las grandes fortalezas de los mocks.
Ventajas y desventajas del Mock Testing
Son fáciles de escribir y potencian el diseño de software testable. En contraposición, como desventaja, dado que el uso de mocks está anclado a pruebas funcionales puede complicar la mantenibilidad de los test unitarios que lo incluyen. Además en general suele implicar mucho código repetitivo o la instalación de un framework.
La buena noticia es que el uso de mocks es tan frecuente que existen muchísimos frameworks en el mercado para generarlos como por ejemplo Mockito, EasyMock o JMockit (para mocking en Java) para hacernos la vida más fácil.
Fake testing
Un objeto fake también contiene una implementación ejecutable, pero con código que no puede llegar a producción. Esto ocurre porque un objeto fake puede tener una implementación más «light» o simplificada del código de producción.
Un ejemplo clásico para entender este elemento es montar una base de datos en memoria para aquellas pruebas que conlleven persistencia de datos o recuperación de los mismos. Gracias a esto, al invocar los servicios que deberían modificar la base de datos en nuestros test unitarios, podremos probar el comportamiento ideal con la confianza de no «romper» nada en un entorno productivo.
Otro ejemplo es, si queremos probar nuestros objetos DAO (Data Access Object), podemos montar una Collection con un conjunto de datos (que además podemos aprovechar para forzar según qué escenario) o vacío y probar todo un flujo CRUD completo. De esta forma evitamos así tener que levantar siquiera una base de datos en memoria, con el tiempo y recursos que ello conlleva.
Ventajas y desventajas del Fake Testing
Una gran ventaja del fake testing es que no necesitamos ningún framework para empezar a usarlo, es una implementación más. Además, como con los mocks, también ayudan a diseñar nuestro software de un modo más «testable».
La última ventaja a destacar es que este código podría ser candidato a código en producción, ya que es código totalmente funcional.
¿Desventaja? pues que, al no existir framework, la velocidad de implementación puede verse perjudicada.
Entonces… ¿con cuál me quedo? ¿Mock o Fake testing?
Tal y como hemos visto, un mock no implementa código funcionando, con lo que no puede probar un sistema completo, lo hace por componentes y la calidad de los tests puede darse según la calidad de los datos de los mocks que se haya montado. En contraposición los fake testings generan código que funciona, que podría probar el sistema completo, ya que es una versión simplificada del código de producción
El uso de fakes en nuestras pruebas unitarias, enfocadas en realizar validaciones basadas en el estado, hace que de forma natural el código de las pruebas unitarias se parezca más al código cliente (cosa que no ocurre usando mocks). Como consecuencia podremos realizar refactorizaciones con una mayor confianza, obtendremos una mayor legibilidad de nuestros tests y tienen un coste de mantenimiento más bajo. Además, probablemente se podrán reutilizar para la siguiente capa de tests de nuestra pirámide de Agile testing: los tests de integración.
¿Quieres seguir aprendiendo sobre Testing de software? Síguenos en nuestras Redes Sociales y Canal de YouTube.
