La semana pasada sentamos las bases de esta serie de post sobre pruebas unitarias, diferenciando entre el sistema que estoy probando (SUT) y las dependencias que tiene dicho sistema (DOC). Dichos elementos serán diferentes en cada tipo de prueba.
Si no sabes de que estoy hablando, te recomiendo el post: ¿Qué estoy probando y cuáles son mis dependencias en testing?
Ahora centrémonos en las pruebas unitarias, en las que nuestro objetivo es probar una unidad de software por si sola, sin las interacciones con el resto de objetos, clases, etc. Si por ejemplo tenemos una clase Coche, con un método vender, que recibe un Cliente como argumento y queremos probar el funcionamiento de ese método, deberemos simular la dependencia Cliente.
Es decir, en una prueba unitaria sobre un SUT (sistema que estoy probando, puede ser una clase, un objeto, etc.), lo que simulamos son las dependencias (DOC).
Digo simular las dependencias aunque puede que lo que más hayas escuchado es “mockear” las dependencias. El uso del término “mockear” está muy extendido, pero en realidad no es del todo correcto, ya que un mock es un tipo de simulación de dependencia, y no siempre es adecuado para el objetivo que andemos buscando.
En general a los objetos que simulan dependencias se les llama test doubles. Por lo que un mock, es un tipo de test double.
Por otra parte, seguro que para mockear te vienen a la cabeza herramientas como Mockito. Eso es correcto, pero a la hora de hacer test doubles, no siempre tiene por qué ser necesario utilizar herramientas o librerías.
Hoy veremos los distintos tipos de test doubles, para entrar en casos prácticos y cuándo es recomendable hacer test doubles en los próximos posts.
Tipos de test doubles
– Dummy: Son objetos que se envían, pero nunca se utilizan en el test.
Por ejemplo, imaginemos que tenemos un objeto de la clase GestorDeTareas, que gestiona objetos Tarea, que necesita una lista de parámetros Tarea para funcionar. Si en el test solo queremos comprobar que uno de sus métodos me devuelva el número de Tareas que contiene ese gestor de tareas, podemos utilizar dummies para rellenar el gestor de tareas. Muchas veces los dummies se rellenan con valores NULL.
– Stub: Es un objeto en el que configuras que cuando llames a un método devuelva un valor determinado. Por ejemplo, si tienes un objeto con un método que suma dos números, un stub sería un objeto que independientemente de los valores que le pases al método suma, devuelva 5.
– Spy: Estos objetos guardan las acciones que se hacen sobre ellos. Hace una especie de seguimiento sobre qué métodos se han llamado y con qué parámetros.
Cuando para que un test sea un éxito no es suficiente ver el estado de los objetos disponibles, podemos usar un spy y comprobar cosas como cuántas veces se ha llamado a un método, qué valores han devuelto, etc.
– Mock: Muy similar a un spy, pero no solo guardan las acciones que se hacen sobre ellos, también es necesario configurar qué comportamiento esperas cuando alguien llame a alguno de sus métodos.
– Fake: Es un objeto que implementado completamente y que funciona, como un objeto normal sin ser simulado, pero se diferencia en que está falseando algo para hacer alguna cosa más fácil de probar. Un ejemplo de esto podría ser un objeto que utiliza una base de datos en memoria en lugar de acceder a consultar la base de datos de producción.
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Las 3 matrices de priorización Ágil - 19 octubre, 2023
- Etapas del Agile Product Management - 12 octubre, 2023
- Agile Product Management: DINÁMICA «Árbol Solución Oportunidad» + «Valores Esperados» - 5 octubre, 2023
Un post conciso y muy útil para repasar 😉
Si lo he entendido bien, ¿un Mock es básicamente una combinación entre un Spy y un Stub? ¿O añade algo más?