Pruebas avanzadas con Mockito

1.1 Biblioteca Mockito

Hoy nos familiarizaremos con las pruebas avanzadas. Más concretamente, con la librería Mockito . Ni siquiera pienses en salir de este negocio.

Primero, esta biblioteca es un estándar en las pruebas de Spring . Que es en realidad el estándar en la industria de desarrollo de back-end de Java.

En segundo lugar, deberá escribir pruebas para su código Spring . La única forma de entender que el backend que escribió funciona como debería es llamar a los métodos de su API . Y hacerlo con pruebas es 10 veces más fácil que sin ellas. Lo verás por ti mismo.

Puedes agregar la biblioteca Mockito a la tuya pom.xmlusando el código:

<dependency>
    <groupId>org.mockito</groupId>
    <artifactId>mockito-junit-jupiter</artifactId>
    <version>4.2.0</version>
    <scope>test</scope>
</dependency>

El código fuente completo del proyecto Mockito se puede encontrar en GitHub .

1.2 Objetos simulados

Entonces, ¿qué es este Mockito y por qué es tan bueno?

En el proceso de desarrollo y formación de pruebas, muy a menudo era necesario insertar algún tipo de "stub" en el código en lugar de un objeto real.

Por ejemplo, el código que funciona con la base de datos se prueba y cambia algo allí. Es bueno que antes de cada prueba el estado de esta base de datos sea el mismo (de lo contrario, las pruebas serán diferentes). Y me gustaría que la base fuera más simple para revertir rápidamente estos estados.

O, por ejemplo, estás probando un código que envía SMS útiles. Y para los envíos directos, utiliza algún tipo de pasarela SMS de pago. Sería bueno deslizar algún Gateway virtual en él para probar el código, para no enviar cientos de SMS a personas incomprensibles.

O su código solicita datos de otros servidores web que simplemente no están disponibles en el servidor de prueba. O escribe un código para pagos en línea que debe probarse 50 veces, y solo entonces se permite su uso en canales financieros reales.

Creo que entiendes... Los objetos virtuales, o como también se les llama objetos stub, son algo muy útil.

Y aquí viene la dificultad: Java tiene escritura estática. Esto significa que para ReadDatabaseasignar una referencia a un objeto a una variable en lugar de un objeto de tipo VirtualDatabase, debe heredar la clase VirtualDatabasede RealDatabase.

Luego resulta que la clase tiene RealDatabaseun montón de métodos y variables privados que almacenan referencias a otros objetos reales, y no puedes escribir un código auxiliar normal de esta manera. En teoría es bueno, pero en la práctica es un callejón sin salida.

Y aquí viene al rescate ( puedes leerDynamicProxy con más detalle ), que apareció en Java 5. Te permite crear objetos virtuales de los que el compilador no tiene quejas.

Dichos objetos virtuales se denominan simulacros (de la palabra simulacro - diseño). La biblioteca de Mockito pudo llevar el trabajo con estos simulacros a una altura sin precedentes. De ahí, por cierto, el nombre de la biblioteca.

1.3 Anotación @ExtendWith

La biblioteca de Mockito funciona muy bien con JUnit, incluso puede considerarse una extensión de la misma.

Hay dos formas de habilitar la biblioteca de Mockito en sus pruebas unitarias. La primera forma es agregar una anotación especial:

@ExtendWith(MockitoExtension.class)
public class MockitoAnnotationTest {
    ...
}

La segunda forma es habilitar su trabajo llamando al método openMocks():

public class MockitoAnnotationTest {
    @BeforeEach
    public void init() {
        MockitoAnnotations.openMocks(this);
   }
}

La mayoría de las veces, verá la primera opción, pero a veces es útil saber que hay una segunda.