Continuamos con la serie de posts sobre pruebas unitarias y cómo “mockear” las dependencias en dichas pruebas unitarias (mediante la creación de test doubles).
La semana pasada vimos qué es un test double, qué tipos de test doubles hay y para qué se utilizan (Simulando las dependencias en las pruebas unitarias. Dummies vs Stubs vs Mocks vs Spies vs Fakes).
Pero, ¿y esto cómo se aplica en el código? ¿cómo se crean los distintos tipos de test doubles?
Teniendo en la cabeza qué características tiene cada tipo de test double, podemos crear dichos objetos de dos formas diferentes:
– o bien nosotros mismos a nivel de código, y sin la ayuda de ninguna librería;
– o con algún framework de testing que nos facilite la tarea. A este tipo de librerías de testing se les llama mocking frameworks, y como ejemplos tenemos Mockito, EasyMock, PowerMock, etc.
Hoy vamos a ver ejemplos escritos en Java manualmente, de los distintos tipos de Test doubles en las pruebas unitarias, sin utilizar ningún mocking framework. Estos test doubles van a ser muy simples, para terminar de asentar los conceptos.
Recuerda que para afrontar este tipo de gestión de dependencias tienes que tener muy claro qué quieres probar en tu prueba unitaria (SUT) y cuáles son las dependencias que necesita dicho elemento (DOCs). Estas últimas son las que simularemos (recuerda el post ¿Qué estoy probando y cuáles son mis dependencias en testing?).
Creando test doubles manualmente, sin ningún tipo de framework
– Stub: Dijimos que este era un tipo de objeto en el que se configuraba que al llamar a alguno de sus métodos en concreto, se devolviera un valor ya configurado.
Imaginemos que tenemos la siguiente clase llamada ShipmentTaxesCalculator:
Esta clase tiene un método que queremos probar (calculateTaxesFor), que dada una información sobre un lugar de envío, nos calcula las tasas que hay que pagar por dicho envío.
El problema es que esta clase depende de la clase BaseTaxesStructure, y un objeto de dicha clase es utilizado en el método que queremos probar.
Realmente, yo en esta prueba unitaria, lo que quiero comprobar es que el método calculateTaxesFor, me devuelve las tasas adecuadas para la información de envío que le paso por parámetro (es decir, hace bien todas las operaciones que estarían en el método calculateTaxesFor por debajo del comentario //More operations with taxes).
No quiero testear la interacción del objeto baseTaxesStructure. Por eso para hacer el test, simulo esa dependencia creando un stub con un valor predeterminado.
– Dummy: Utilizamos este tipo de test doubles para simular objetos que se necesitan pasar como argumentos, pero no se utilizan en la prueba untiaria.
Imaginemos que queremos simular una lista de un carrito de la compra, con varios productos, y hacer una prueba de que dicha lista se rellene bien, comprobar solo el tamaño de la lista, cuántos elementos tiene.
En este caso, no me importa el contenido de los productos, porque no es el objeto de mi prueba, por lo que esos objetos son dummies.
-Fake: Simulaciones más ligeras de ciertos procesos, que permiten ejecutar pruebas del resto de elementos que van después de dichos procesos más rápido, y que de otra forma sería muy complicado.
Imaginemos que tenemos un sistema que gestiona eventos de teatros. Cada evento tiene varias sesiones (una a las 10.00 am, otra a las 14.00 pm, etc.) y cada sesión tiene un aforo determinado, con entradas que salen a la venta.
Tenemos un proceso que para cada una de dichas sesiones, genera una entrada por asiento del aforo y la guarda en base de datos.
Este proceso se vuelve muy pesado si el evento tiene muchas sesiones, con teatros con muchísimo aforo, porque el sistema tiene que generar muchísimas entradas.
Si queremos probar alguna parte de código que dependa de ese proceso una opción simular este proceso de alguna otra manera (reduciendo el número de aforo, utilizando otro tipo de base de datos, memoria intermedia, etc.).
—
La semana que viene veremos qué son los mocking frameworks y terminaré con los ejemplos de código de mocks y spies.
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