Burlarse de las variables miembro de una clase usando Mockito

Question 1

Soy un novato en el desarrollo y en las pruebas unitarias en particular. Supongo que mi requisito es bastante simple, pero estoy ansioso por conocer los pensamientos de otros sobre esto.

Supongamos que tengo dos clases así:

public class First {

    Second second ;

    public First(){
        second = new Second();
    }

    public String doSecond(){
        return second.doSecond();
    }
}

class Second {

    public String doSecond(){
        return "Do Something";
    }
}

Digamos que estoy escribiendo prueba unitaria para probar First.doSecond() método. Sin embargo, supongamos que quiero burlarme Second.doSecond() clase así. Estoy usando Mockito para hacer esto.

public void testFirst(){
    Second sec = mock(Second.class);
    when(sec.doSecond()).thenReturn("Stubbed Second");

    First first = new First();
    assertEquals("Stubbed Second", first.doSecond());
}

Estoy viendo que la burla no surte efecto y la afirmación falla. ¿No hay forma de burlarse de las variables miembro de una clase que quiero probar? ?

Question 2

Debe proporcionar una forma de acceder a las variables miembro para que pueda pasar un simulacro (las formas más comunes serían un método setter o un constructor que toma un parámetro).

Si su código no proporciona una forma de hacer esto, se factoriza incorrectamente para TDD (Desarrollo dirigido por pruebas).

Question 3

Esto no es posible si no puede cambiar su código. Pero me gusta la inyección de dependencia y Mockito lo admite:

public class First {    
    @Resource
    Second second;

    public First() {
        second = new Second();
    }

    public String doSecond() {
        return second.doSecond();
    }
}

Su prueba:

@RunWith(MockitoJUnitRunner.class)
public class YourTest {
   @Mock
   Second second;

   @InjectMocks
   First first = new First();

   public void testFirst(){
      when(second.doSecond()).thenReturn("Stubbed Second");
      assertEquals("Stubbed Second", first.doSecond());
   }
}

Esto es muy bonito y fácil.

Question 4

Si observa detenidamente su código, verá que el second propiedad en su prueba sigue siendo una instancia de Secondno un simulacro (no le pasas el simulacro a first en su código).

La forma más sencilla sería crear un setter para second en First class y pasarle el simulacro explícitamente.

Como esto:

public class First {

    Second second ;

    public First(){
        second = new Second();
    }

    public String doSecond(){
        return second.doSecond();
    }

    public void setSecond(Second second) {
        this.second = second;
    }


}

class Second {

    public String doSecond(){
        return "Do Something";
    }
}

....

public void testFirst(){
Second sec = mock(Second.class);
when(sec.doSecond()).thenReturn("Stubbed Second");


First first = new First();
first.setSecond(sec)
assertEquals("Stubbed Second", first.doSecond());
}

Otra sería pasar un Second instancia como FirstParámetro constructor de .

Si no puede modificar el código, creo que la única opción sería usar la reflexión:

public void testFirst(){
    Second sec = mock(Second.class);
    when(sec.doSecond()).thenReturn("Stubbed Second");


    First first = new First();
    Field privateField = PrivateObject.class.
        getDeclaredField("second");

    privateField.setAccessible(true);

    privateField.set(first, sec);

    assertEquals("Stubbed Second", first.doSecond());
}

Pero probablemente puedas, ya que es raro hacer pruebas en un código que no controlas (aunque uno puede imaginar un escenario en el que tiene que probar una biblioteca externa porque su autor no lo hizo :))

Question 5

Si no puede cambiar la variable miembro, al revés, use powerMockit y llame

Second second = mock(Second.class)
when(second.doSecond()).thenReturn("Stubbed Second");
whenNew(Second.class).withAnyArguments.thenReturn(second);

Ahora el problema es que CUALQUIER llamada a new Second devolverá la misma instancia simulada. Pero en su caso simple esto funcionará.

Question 6

Tuve el mismo problema en el que no se estableció un valor privado porque Mockito no llama a los superconstructores. Así es como aumento la burla con la reflexión.

Primero, creé una clase TestUtils que contiene muchas utilidades útiles, incluidos estos métodos de reflexión. El acceso a la reflexión es un poco difícil de implementar cada vez. Creé estos métodos para probar código en proyectos que, por una u otra razón, no tenían un paquete de simulación y no me invitaron a incluirlo.

public class TestUtils {
    // get a static class value
    public static Object reflectValue(Class<?> classToReflect, String fieldNameValueToFetch) {
        try {
            Field reflectField  = reflectField(classToReflect, fieldNameValueToFetch);
            reflectField.setAccessible(true);
            Object reflectValue = reflectField.get(classToReflect);
            return reflectValue;
        } catch (Exception e) {
            fail("Failed to reflect "+fieldNameValueToFetch);
        }
        return null;
    }
    // get an instance value
    public static Object reflectValue(Object objToReflect, String fieldNameValueToFetch) {
        try {
            Field reflectField  = reflectField(objToReflect.getClass(), fieldNameValueToFetch);
            Object reflectValue = reflectField.get(objToReflect);
            return reflectValue;
        } catch (Exception e) {
            fail("Failed to reflect "+fieldNameValueToFetch);
        }
        return null;
    }
    // find a field in the class tree
    public static Field reflectField(Class<?> classToReflect, String fieldNameValueToFetch) {
        try {
            Field reflectField = null;
            Class<?> classForReflect = classToReflect;
            do {
                try {
                    reflectField = classForReflect.getDeclaredField(fieldNameValueToFetch);
                } catch (NoSuchFieldException e) {
                    classForReflect = classForReflect.getSuperclass();
                }
            } while (reflectField==null || classForReflect==null);
            reflectField.setAccessible(true);
            return reflectField;
        } catch (Exception e) {
            fail("Failed to reflect "+fieldNameValueToFetch +" from "+ classToReflect);
        }
        return null;
    }
    // set a value with no setter
    public static void refectSetValue(Object objToReflect, String fieldNameToSet, Object valueToSet) {
        try {
            Field reflectField  = reflectField(objToReflect.getClass(), fieldNameToSet);
            reflectField.set(objToReflect, valueToSet);
        } catch (Exception e) {
            fail("Failed to reflectively set "+ fieldNameToSet +"="+ valueToSet);
        }
    }

}

Entonces puedo probar la clase con una variable privada como esta. Esto es útil para burlarse de los árboles de clase que no tiene control.

@Test
public void testWithRectiveMock() throws Exception {
    // mock the base class using Mockito
    ClassToMock mock = Mockito.mock(ClassToMock.class);
    TestUtils.refectSetValue(mock, "privateVariable", "newValue");
    // and this does not prevent normal mocking
    Mockito.when(mock.somthingElse()).thenReturn("anotherThing");
    // ... then do your asserts
}

Modifiqué mi código de mi proyecto real aquí, en page. Podría haber un problema de compilación o dos. Creo que entiendes la idea general. Siéntete libre de tomar el código y usarlo si lo encuentras útil.

Question 7

Puede burlarse de las variables miembro de un Mockito Mock con ReflectionTestUtils

ReflectionTestUtils.setField(yourMock, "memberFieldName", value);

Question 8

Si quieres una alternativa a ReflectionTestUtils de Spring en mockito, usa

Whitebox.setInternalState(first, "second", sec);

¿Ha sido útil esta solución?