Знущання зі змінними членів класу за допомогою Mockito

Я новачок у розробці та зокрема в одиницях тестів. Я думаю, моя вимога досить проста, але я прагну знати інші думки з цього приводу.

Припустимо, у мене є два такі класи -

public class First {

    Second second ;

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

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

class Second {

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

Скажімо, я пишу одиничний тест на First.doSecond()метод тестування . Однак, припустимо, я хочу так, щоб Second.doSecond()клас Mock виглядав так. Для цього я використовую Mockito.

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

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

Я бачу, що глузування не спрацьовує, і твердження провалюється. Чи немає способу знущатися зі змінних членів класу, який я хочу перевірити. ?

Вам потрібно надати спосіб доступу до змінних-членів, щоб ви могли передати макет (найпоширенішими способами буде метод сеттера або конструктор, який приймає параметр).

Якщо ваш код не передбачає способу цього, він неправильно враховується для TDD (Test Driven Development).

Це неможливо, якщо ви не можете змінити свій код. Але мені подобається введення залежності, і Mockito підтримує це:

public class First {    
    @Resource
    Second second;

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

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

Ваш тест:

@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());
   }
}

Це дуже приємно і просто.

Якщо ви уважно подивитесь на свій код, то побачите, що secondвластивість у вашому тесті все ще є екземпляром Second, а не макетом (ви не передаєте макет firstу свій код).

Найпростіший спосіб буде створити сетер для secondв Firstкласі і передати йому знущатися явно.

Подобається це:

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());
}

Іншим було б передати Secondекземпляр як Firstпараметр конструктора.

Якщо ви не можете змінити код, я думаю, що єдиним варіантом буде використання відображення:

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());
}

Але ви, мабуть, можете, оскільки це рідко робити тести на код, який ви не контролюєте (хоча можна уявити сценарій, коли вам доведеться перевірити зовнішню бібліотеку, оскільки її автор не зробив :)

Якщо ви не можете змінити змінну члена, то навпаки можна використовувати powerMockit та зателефонувати

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

Тепер проблема полягає в тому, що будь-який виклик до нового Second поверне той самий глузливий екземпляр. Але у вашому простому випадку це спрацює.

У мене було те саме питання, коли приватне значення не було встановлено, оскільки Mockito не називає суперконструкторів. Ось як я збільшую глузування з роздумів.

По-перше, я створив клас TestUtils, який містить багато корисних утиліт, включаючи ці методи відображення. Доступ до рефлексії є дещо химерним для впровадження кожного разу. Я створив ці методи для тестування коду для проектів, які з тих чи інших причин не мали глузуючого пакету, і мене не запропонували включити.

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);
        }
    }

}

Тоді я можу протестувати клас із приватною змінною, як ця. Це корисно для знущань над глибокими деревами класу, над якими ви також не маєте контролю.

@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
}

Я змінив свій код зі свого фактичного проекту тут, на сторінці. Може виникнути питання про компіляцію чи два. Я думаю, ви отримаєте загальну думку. Сміливо захопіть код і скористайтеся ним, якщо вам здається корисним.

Багато хто вже радив вам переосмислити свій код, щоб зробити його більш перевіреним - хороша порада і, як правило, простіша, ніж те, що я пропоную.

Якщо ви не можете змінити код, щоб зробити його більш випробуваним, PowerMock: https://code.google.com/p/powermock/

PowerMock розширює Mockito (так що вам не доведеться вивчати нову схему макетів), забезпечуючи додаткову функціональність. Сюди входить можливість змусити конструктор повернути макет. Потужний, але трохи складний - тому використовуйте його розумно.

Ви використовуєте інший Mock runner. І вам потрібно підготувати клас, який збирається викликати конструктор. (Зауважте, що це звичайний gotcha - підготуйте клас, який викликає конструктор, а не сконструйований клас)

@RunWith(PowerMockRunner.class)
@PrepareForTest({First.class})

Потім у вашій тестовій настройці ви можете використовувати метод WhenNew, щоб конструктор повернув макет

whenNew(Second.class).withAnyArguments().thenReturn(mock(Second.class));

Так, це можна зробити, як показує наступний тест (написаний з глузливим API JMockit, який я розробляю):

@Test
public void testFirst(@Mocked final Second sec) {
    new NonStrictExpectations() {{ sec.doSecond(); result = "Stubbed Second"; }};

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

Однак із Мокіто такий тест не може бути складений. Це пояснюється тим, як макетування реалізується в Mockito, де створюється підклас класу, який слід знущатися; лише екземпляри цього "макетного" підкласу можуть насміхатися з поведінкою, тому потрібно мати тестований код використовувати їх замість будь-якого іншого екземпляра.

Якщо ви хочете альтернативу ReflectionTestUtils з Spring у макеті, використовуйте

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