java - all - mockito verify
¿No se recomienda utilizar @Spy y @InjectMocks en el mismo campo? (2)
En el proyecto en el que estoy trabajando en este momento, a menudo veo que @Spy y @InjectMocks usan juntos en un campo. Pero nunca lo he visto de esta manera en ningún tutorial u otros recursos. Busqué en Google después de esta combinación específica, pero no encontré nada más que este hilo en GitHub: https://github.com/mockito/mockito/issues/169
Lo que me hace pensar que lo estamos utilizando de una manera extraña.
Nota: la razón por la que creo que usar ambas anotaciones juntas tiene sentido a veces es porque si solo usas @InjectMocks Mockito intenta crear una instancia de la clase con un constructor sin argumentos. Pero si no tiene un contructor sin @Spy y agrega @Spy , puede usar el objeto sin necesidad de un constructor vacío.
Edición: Otro uso importante es que solo puede eliminar métodos si solo usa ambas anotaciones.
Cada anotación tiene diferentes propósitos y no se pisan entre sí con claridad siempre que sea necesario utilizar simulacros parciales. (también conocido como método (s) relacionado (s) que ya ha sido probado y / o de confianza)
Por ejemplo, tiene una clase para probar, que tiene inyecciones de dependencia que no tienen que ser reales, por lo que desea @InjectMocks. Además, el método que está probando llama a otro método interno, que ya se probó en algún lugar, o llama a una referencia externa que probablemente también se probó de forma independiente. Por lo tanto, no desea que se moleste en probar los mismos métodos más de una vez, y su código de prueba no debe verse afectado por el cambio de implementación fuera del alcance en ningún momento en el futuro.
Solo los pares @Mock & @Spy, o @Mock & @InjectMocks no tienen sentido.
Es poco común, y posiblemente inapropiado, usar @Spy y @InjectMocks juntos.
@InjectMocks funciona como una especie de inyección de dependencia para el sistema bajo prueba: si tiene una prueba que define un @Mock o @Spy del tipo correcto, Mockito inicializará cualquier campo en su instancia de @InjectMocks con esos campos. Esto podría ser útil si de otra manera no ha estructurado su sistema bajo prueba para la inyección de dependencia (o si utiliza un marco DI que realiza la inyección de campo) y desea reemplazar esas dependencias con simulacros. Puede ser bastante frágil: los campos no coincidentes se ignorarán silenciosamente y permanecerán null si no están configurados en un inicializador, pero siguen siendo una anotación decente para su sistema bajo prueba .
@Spy , como @Mock, está diseñado para configurar dobles de prueba ; Debe usarlo cuando tenga un colaborador que desee anular o verificar. Tenga en cuenta que @Spy y @Mock siempre son para dependencias y no para su sistema bajo prueba .
Idealmente, no debería tener ninguna clase que cumpla con ambos roles en la misma prueba, o de lo contrario podría estar escribiendo una prueba que evalúe minuciosamente el comportamiento que ha tachado en lugar del comportamiento de producción real. En cualquier caso, será más difícil decir exactamente qué cubre la prueba en comparación con el comportamiento que ha tachado.
Por supuesto, es posible que esto no se aplique si está tratando de usar Mockito para probar un solo método de forma aislada, y desea detener las llamadas a un método mientras prueba el otro. Sin embargo, esto también podría ser una indicación de que su clase está violando el Principio de Responsabilidad Única, y que debe dividir la clase en varias clases independientes que trabajen juntas. Luego, en su prueba, puede permitir que las instancias tengan exactamente un rol y nunca necesiten las dos anotaciones a la vez.