Когда вы макетируете класс в mockito framework, вы вставаете фактический класс вручную?

Question

Я довольно новичок в мокито-фреймворке.Я читал несколько уроков по этому поводу.Один из них, за которым я следовал, таков: https://www.tutorialspoint.com/mockito/mockito_first_application.htm

Есть заявление, создающее макет Службы акций.

In this example, we've created a mock of Stock Service to get the dummy price of some stocks

Мой вопрос Stock Servicea real service class или mock service class Вы должны вручную встать для имитации реального класса обслуживания.Я немного смущен.Имея базовое понимание основ Junit.То, что я практиковал раньше, было, если есть класс обслуживания Foo, тогда я использовал реальный класс, который предоставляет все доступные методы.

public class Foo {

    public Foo() { } // construtor

    public String returnAddress(String userId) {
        // ...
        return dataAccesobj.getAddress(userId);
    }
}

Вызов foo.returnAddress(..) в модульном тесте, если я правильно помню.

Причина, по которой я задаю этот вопрос, заключается в том, что, работая с mockito над созданием метода тестирования для класса, я столкнулся с уникальным (?) Испытанием.

Я начал среальный класс обслуживания, который зависит от своего конструктора суперкласса для возврата своего экземпляра.Проблема, с которой я столкнулся, заключалась в том, что этот конструктор суперкласса инициирует соединение с БД и загрузку / разбор файлов свойств, которые мне не нужны для моего теста.Я думал о том, как предотвратить подключение к БД и загрузку / чтение файлов пропов ....

Мне показалось, что я прочитал одно из mockito учебных пособий, в которых можно изолировать тестирование, не имея таких сервисов.Я пробовал с @Mock и @Spy (не до конца понимая, для чего они нужны ...), но это не имело значения для вывода (возможно, я неправильно использовал эти аннотации).

Итак, я фактически создал класс fake / mock из реального класса обслуживания (например, Foo), просто скопировав его и переименовав в FooMock и поместив в папку src/test/java, где находится модуль.тестовый класс работает с.Я держал класс mock точно таким же, как и реальный класс обслуживания, за исключением удаления ненужной логики, такой как db connection или loading/reading prop file for env specific.Сделав это, я смог протестировать один из открытых методов, которые читают каталог ldap ...

Извините, я отвлекся, но надеюсь, что моя точка зрения ясна на данный момент.Я не уверен, что то, как я справился с этой ситуацией, правильно или неправильно.Я был бы признателен опытным инженерам, которые бы разъяснили, как я справляюсь с вопросом, приемлемо mockito или нет.Если нет, то, пожалуйста, посоветуйте мне лучший способ справиться с этим.

Answer 1

В Mockito mock - это реализация класса-оболочки.Имитируемый объект «оборачивает» цель макета (сервис в вашем примере) и позволяет вам определить функциональность каждого метода.

В Mockito есть две опциональные опции функциональности;вызовите упакованный метод и не вызывайте упакованный метод.

Я не знаю, когда имеет смысл вызывать упакованный метод, поэтому я всегда использую не вызывать упакованный метод.

После создания макета используйте метод Mockito.doReturn (returnvalue) .when (mockObject) .method (параметры метода) для макета функциональности.

Редактирование: дополнительная информация.

Я предполагаю, что вы используете junit v4.Детали этого будут различаться в зависимости от номера основного выпуска junit, но фактическая работа будет такой же.

1. Используйте аннотации для определения ваших Mock объектов (@Mock), за исключением несколькихОсобые случаи.Это создаст макеты не финальных классов, абстрактных классов и интерфейсов.
2. Создайте метод «перед тестированием», используя аннотацию @Before;Я традиционно называю этот метод preTestSetup, но фактическое имя не имеет значения.
3. Вызовите MockitoAnnotations.initMocks(this) в качестве первой строки кода в методе «before-test».Это найдет аннотации @Mock и создаст экземпляр макета для каждого.
4. Используйте метод ReflectionTestUtils.setField, чтобы ввести макеты в ваш объект (при условии, что у вас нет методов установки, которые я традиционно не использую)t like).
5. Определите фиктивную функциональность каждого метода с помощью техники Mockito.doReturn(returnvalue).when(mockObject).method(method parameters).

Вот пример кода (предостережение: это должно быть полностью функционально, но я сделалне скомпилировать):

public interface MyService
{
    String blammy(SomeParameter parameter);
}

public class UsesMyService
{
    @Autowired
    private MyService myService;

    public String kapow(final SomeParameter parameter)
    {
        return myService.blammy(parameter);
    }
}

public class UnitTestUsesMyService
{
    private UsesMyService classToTest;

    @Mock
    private MyService mockMyService;

    @Mock
    private SomeParameter mockSomeParameter;

    @Before
    public void preTestSetup()
    {
        MockitoAnnotations.initMocks(this);

        classToTest = new UsesMyService();

        doReturn("Blam").when(mockMyService).blammy(mockSomeParameter);

        ReflectionTestUtils.setField(
            classToTest,
            "myService",
            mockMyService);
    }

    @Test
    public void kapow_allGood_success()
    {
        final String actualResult;


        actualResult = classToTest.kapow(mockSomeParameter);


        assertNotNull(actualResult); // Not strictly necessary.

        assertEquals(
            "Blam",
            actualResult);
    }
}