Mockito 2: la librería de mocks por excelencia en Java adquiere nuevos poderes

Es indiscutible que Mockito se ha transformado en una librería de referencia para crear Mocks en los tests unitarios escritos en Java y otros lenguajes de la JVM.

Su simplicidad de empleo unida a su potencia la han hecho una de las favoritas entre aquellos que desean redactar tests para validar su software.

Hace unos meses, el equipo que desarrolla Mockito lanzó al fin la versión final de Mockito dos. Una actualización que ha añadido un buen número de novedades bien interesantes, y que el día de hoy deseo presentarte.

Mockito dos deja mockear clases y métodos finales

Novedades en Mockito 2

Mockito dos ha añadido múltiples funcionalidades verdaderamente útiles, que van a facilitar la labor de redactar tests más fáciles y útiles.

Además de esto, ahora deja crear mocks de ciertas cosas que ya antes eran imposibles.

Acá te cuento cuáles son las novedades:

Ahora advierte qué mocks no son necesarios

De este modo es. En el momento en que un test contenga un mock que no es usado, la ejecución va a fallar. De esta manera evitamos crear mocks superfluos, y los tests se vuelven más inteligibles.

Si deseas, puedes eludir que esto ocurra usando el runner MockitoJUnitRunner.Silent.class, mas la verdad que es algo bastante útil.

Muchas mejoras en los matchers

Con la meta de ser más preciso, ciertos matchers han alterado su comportamiento.

Por poner un ejemplo, ahora any() no incluye valores nulos. Es buena forma de advertir dónde somos demasiado flexibles con nuestras condiciones del test.

Si deseamos detallar que deseamos un valor nulo para el factor, podemos emplear el matcher isNull(). Y si deseamos un comportamiento afín al antigo, entonces podemos usar nullable().

Otro ejemplo es que anyInt() ahora no admite valores de tipo long. De ahora en adelante deberás emplear anyLong() en esos casos.

Por fin puedes mockear lo inmockeable

Mockito dos deja mockear clases y métodos finales. Esto es una muy buena nueva, en tanto que vamos a poder eludir que nuestras clases o bien métodos sean extendidos, y no comprometer nuestro código por el hecho de precisar testarlo. Caso de que no se quiera que se use herencia, se debería prohibir, como se señala en el item diecisiete de Effective Java.

Además de esto, esta feature se vuelve prácticamente indispensable para otros lenguajes como Kotlin, donde sus clases y funciones son cerradas (finales) por defecto.

Esta característica es parcialmente experimental, conque para activarla hay que hacer ciertos ajustes. Si deseas usarlo, en el artículo explico de qué forma.

Cómo migrar de Mockito a Mockito 2

Habitualmente, esta migración va a ser prácticamente inmediata. Mas posiblemente te halles inconvenientes, y que ciertos tests que funcionaban comiencen a fallarte.

Estos son los puntos con los que me he encontrado, mas seguro que hay alguno más:

Necesitas alterar el bulto del runner

Si usas el runner de Mockito, vas a ver que de ahora en adelante te aparecerá como deprecado.

Esto es por el hecho de que han movido el runner a otro bulto, conque una simple substitución debería funcionarte:

Este era el viejo paquete:

import org.mockito.runners.MockitoJUnitRunner;

Y este el nuevo:

import org.mockito.junit.MockitoJUnitRunner;

Actualizar ciertos matchers

Como comentaba arriba, los matchers any() ya no validan factores null. Yo me hallé con múltiples de estos, y acostumbran a ser un pequeño fragancia en los tests, puesto que señalan que están validando cualquier cosa.

El paso de null como factor acostumbra a ser prácticamente siempre y en todo momento un caso que precisa un tratamiento singular, con lo que puede ser interesante extender ese tests en dos: uno que use any(), y otro que use isNull().

La opción alternativa más veloz, no obstante, es substituir los any() que fallen por nullable().

Eliminar los stubs innecesarios

Acá no vas a tener mucho inconveniente, por el hecho de que los fallos en los tests te van a marcar precisamente qué líneas te sobran.

En alguna ocasión me he encontrado con algún stub que no hacía nada, mas mejoraba la legibilidad. Por servirnos de un ejemplo, mockear un procedimiento que devuelve un boolean y también apuntarle que retorne false.

Acá ya va en cuestión de gustos. Yo prefiero sostener esta feature activa y evitarme otros que sí que sean superfluos.

Conclusión

Como ves, Mockito dos trae muchas novedades que van a hacer tus tests más robustos y fáciles.

Han puesto mucho esmero en solucionar todas y cada una de las faltas de la primera versión, y el resultado es verdaderamente interesante.

Y , ¿estás ya utilizando Mockito dos? ¿Cuáles son las nuevas peculiaridades que más te ayudan? La sección de comentarios es tuya.

hljs.initHighlightingOnLoad();

code.hljs undefined
@media only screen and (min-width: 768px) undefined
@media only screen and (min-width: 1024px) undefined

En turincon.net | Desmitificando los dobles de test: Mocks, stubs and friends
Lugar oficial de Mockito

Asimismo te invitamos a

Testando tus aplicaciones Java con Spock: tests más expresivos, simples de leer y sostener

¿Exactamente en qué podemos los españoles prosperar en seguridad vial en dos mil diecisiete?

Test automáticos con QuickCheck ¿De qué manera examinar nuestro código en pos de bugs?

– La nueva

Mockito 2: la librería de mocks por antonomasia en Java adquiere nuevos poderes

fue publicada originalmente en

turincon.net

por
Antonio Leiva

.