Nuestros desarrolladores estrellas han agotado sus depósitos de café, por su búsqueda noche y día por la resolución, hasta que Esmeralda encontró la solución en Gogs y hoy la compartimos contigo.
Solución:
Si está utilizando Spring (específicamente la biblioteca de prueba de primavera), simplemente puede usar ReflectionTestUtils.setField en lugar de Whitebox.setInternalState
Tenga en cuenta que Whitebox siempre estuvo en el org.mockito.internal paquete. Más allá del incremento del número de versión principal, el internal la designación es un obsequio de que el paquete puede estar sujeto a cambios importantes.
Si desea asegurarse de establecer campos inaccesibles en su prueba, puede hacerlo de la misma manera que setInternalState hace, que es solo para identificar el campo en la jerarquía, llame setAccessible en él, y luego configúrelo. El código completo está aquí en grepcode. También puede examinar otras formas de establecer un estado inaccesible en las pruebas.
public static void setInternalState(Object target, String field, Object value)
Class c = target.getClass();
try
Field f = getFieldFromHierarchy(c, field); // Checks superclasses.
f.setAccessible(true);
f.set(target, value);
catch (Exception e)
throw new RuntimeException(
"Unable to set internal state on a private field. [...]", e);
Sin embargo, En situaciones como esta, mi consejo general es deja de pelear con las herramientas: Los cuatro niveles de encapsulación de Java (público, protegido, paquete, privado) no son necesariamente lo suficientemente granulares para expresar el grado de protección que está tratando de expresar y, a menudo, es mucho más fácil agregar un método de inicialización bien documentado o una anulación del constructor para anula las dependencias como intentas hacerlo reflexivamente. Si coloca sus pruebas en el mismo paquete de Java que la clase que prueba, a menudo puede incluso hacer que los campos o el paquete de método/constructor sean privados, lo que también es una buena razón para configurar carpetas de origen paralelas. src y tests (etc) que representan dos mitades del mismo paquete Java.
Aunque algunos tratan este método o constructor adicional como “contaminación de API”, yo lo veo como una codificación según los requisitos de uno de los consumidores más importantes de su clase:su propia prueba. Si necesita una interfaz externa impecable, puede definir fácilmente una por separado de modo que pueda ocultar cualquier detalle que desee. Sin embargo, es posible que te encuentres me gusta la capacidad de inyectar cualquier implementación real o simulada directamente en su componente ahora más flexible, momento en el que es posible que desee buscar patrones o marcos de inyección de dependencia.
Puedes usar FieldSetter en Mockito2.x
import org.mockito.internal.util.reflection.FieldSetter;
FieldSetter.setField(eventHandler,eventHandler.getClass().getDeclaredField("securityService"), securityService);
Aquí tienes las comentarios y valoraciones
Si para ti ha resultado provechoso este post, nos gustaría que lo compartas con más desarrolladores de este modo nos ayudas a extender este contenido.