Dobles de prueba

Uno de los elementos básicos (al menos para mi) para tener un software de calidad es el testing. Una herramienta indispensable para poder tener test que nos aporten ese ciclo de feedback rápido y esa seguridad sin romper el flujo de desarrollo son los dobles de prueba.

El tener mocks, stubs y spies nos permite hacer test de caja gris sin los cuales no tendríamos la facilidad de cubrir todas las ramas de ejecución de nuestro software. El problema de los doble de test reside en que si se usan demasiado se pueden converir en un andamiaje que no nos permite avanzar en el proyecto. Un ejemplo de ello podría ser un código que siempre que cambia nos fuerza a cambiar su test aunque su comportamiento observable sea el mismo.

Con este contexto me gustaría compartir algunas cosas que yo hago, y que creo que me funcionan:

• Yo (casi) nunca mockeo (o stub o spy) algo que sea un objeto plano del lenguaje, por ejemplo, una data class, un servicio que hace cálculos o mapeos sin dependencias externas, etc...
• No resulvo con un Stub lo que se puede resolver con un ObjectMother. Los objetos que son pesados de crear repetitivamente se merecen un Mother.
• Si una clase, o un método, siempre te obligan a cambiar su respectiva suite de test, intenta mover la suite un nivel por encima y abstraerte hacia comportamiento observable. ¿Qué resultado se puede observar de un objeto que llama a base de datos además de espiar esa llamada? Quizás en algunos casos podríamos observar directamente un mock sobre la base de datos en lugar de las interacciones con su repositorio.

Este tema da para escribir infinitos posts y hablar durante horas. Si te interesan no solo los dobles de prueba si no como enfocar estrategias de testing te recomiendo el episodio "Sobre Testing" que grabamos Ronny Ancorini y yo en nuestro podcast The Big Branch Theory Podcast.

Photo by Andre Mouton from Pexels