tutorial - pruebas unitarias spring boot

¿Unidades de prueba de una clase con notación automática usando Junit y EasyMock?

Question

Estoy tratando de escribir una prueba de unidad para una clase que tiene varios de sus campos marcados como @Autowired. Dado que Spring está resolviendo automáticamente las implementaciones concretas para estos campos, me resulta difícil descubrir cómo conectar mis objetos simulados (creados a través de EasyMock) como las dependencias durante la ejecución de la prueba. Usar @Autowired en la clase significa la falta de configuradores en esa clase. ¿Hay alguna manera de que conecte mis objetos simulados sin crear configuradores adicionales en clase?

Aquí hay un ejemplo de lo que estoy tratando de lograr:

public class SomeClassUnderTest implements SomeOtherClass{
@Autowired
private SomeType someType;
@Autowired
private SomeOtherType someOtherType;
@Override
public SomeReturnType someMethodIWouldLikeToTest(){
//Uses someType and someOtherType and returns SomeReturnType
}
}

Así es como estoy elaborando mi clase de prueba antes de golpear la pared:

public class MyTestClassForSomeClassUnderTest{
private SomeType someType;
private SomeOtherType someOtherType;
@Before
public void testSetUp(){
SomeClassUnderTest someClassToTest = new SomeClassUnderTest();
someType = EasyMock.createMock(SomeType.class);
someOtherType = EasyMock.createMock(SomeOtherType.class);
//How to set dependencies????
}
@Test
public void TestSomeMethodIWouldLikeToTest(){
//??????
}
}

Será genial conseguir un empujón en la dirección correcta.

Gracias

Answer 1

Aunque es posible establecer estos campos a través de la reflexión, al hacerlo evitará que sus herramientas de desarrollo encuentren usos de estos campos y dificultará que refactorice SomeClassToTest en el futuro.

Sería mejor agregar definidores públicos para estos campos, y colocar las anotaciones @Autowired en estos en su lugar. Esto no solo evita la reflexión, sino que también aclara la interfaz externa de la clase y asegura que su prueba de unidad use solo esta interfaz. Veo que SomeClassToTest ya implementa la interfaz SomeOtherClass , y asumo que los clientes de SomeClassToTest solo usan esta interfaz, por lo que hay poco peligro en hacer públicos los SomeClassToTest en SomeClassToTest .

Mejor aún, use la inyección de constructor y haga los campos finales. Aún puedes usar @Autowired en los argumentos del constructor.

Answer 2

No recomiendo la respuesta que fue aceptada, es decir, usar la reflexión por tu cuenta (sin un marco burlón).

Desde la versión 3.2 de EasyMock puede usar anotaciones para definir los simulacros e inyectarlos en la clase bajo prueba. Puede encontrar una descripción completa de cómo hacerlo en la documentación oficial de EasyMock: http://easymock.org/user-guide.html#mocking-annotations

Aquí hay un ejemplo del sitio mencionado anteriormente:

import static org.easymock.EasyMock.*;
import org.easymock.EasyMockRunner;
import org.easymock.TestSubject;
import org.easymock.Mock;
import org.junit.Test;
import org.junit.runner.RunWith;
@RunWith(EasyMockRunner.class)
public class ExampleTest {
@TestSubject
private ClassUnderTest classUnderTest = new ClassUnderTest(); // 2
@Mock
private Collaborator mock; // 1
@Test
public void testRemoveNonExistingDocument() {
replay(mock);
classUnderTest.removeDocument("Does not exist");
}
}

Answer 3

Puede inyectar dependencias directamente en el campo mediante ReflectionTestUtils , por ejemplo,

ReflectionTestUtils.setField( testInstance, "fieldName", fieldValue );

Algunos dirían que es preferible agregar un método de configuración visible para el paquete a la clase de todos modos, utilizado únicamente por las pruebas. Alternativamente, use constructores con cableado automático, en lugar de campos con cableado automático, e inyecte las dependencias de prueba en eso.