Как точно работает этот тест весеннего блока, который использует макет?

Question

Я изучаю сертификацию Spring Core, и у меня есть некоторые сомнения относительно использования макета в тесте JUnit.

Я знаю, что, в отличие от пней, где я должен реализовать интерфейс для создания поддельного объекта (мой стаб), используя макет Я использую насмешливые рамки (как EasyMock), которые создают для меня макет объекта используется в моих тестах.

Так шаги для тестирования с помощью издеваться являются следующими:

1. Использования насмешливых библиотек для создания фиктивного объекта, который реализует зависимый интерфейс на лету

2. Запись макет с ожиданием того, как он будет использоваться для сценария: какие методы будут называться и Какие значения должны быть возвращены

3. Упражнение сценарий

4. Проверка имитировали ожидания были выполнены

Так, например, я могу иметь следующий тестовый класс:

import static org.easymock.classextensions.EasyMock.*; 

public class AuthenticatorImplTests { 

    // 1) Implementation of AccountRepository interface is created: 
    private AccountRepository accountRepository = createMock(AccountRepository.class); 

    private AuthenticatorImpl authenticator = new AuthenticatorImpl(accountRepository); 

    @Test 
    public void validUserWithCorrectPassword() { 

     // 2) RECORDING: What behavior to expect? 
     expect(accountRepository.getAccount(“lisa”)).andReturn(new Account(“lisa”, “secret”)); 

     // Recording Playback (???) 
     replay(accountRepository); 

     // 3) Excercise the scenario: 
     boolean res = authenticator.authenticate(“lisa”, “secret”); 
     assertTrue(res); 

     // 4) Verify mock expectations were met 
     verify(accountRepository); 
    } 
} 

Хорошо, есть что-то, что очень ясно для меня, но есть некоторые другие вещи, которые я не могу понять.

Что происходит?

Мне кажется, что:

1. Он создан во время выполнения макета реализации зависимости, представленной интерфейса AccountRepository, необходимого для тестирования AuthenticatorImpl класса в качестве единицы.

2. Мой издеваться записываются с ожиданиями того, как он будет использоваться для определенного сценария, в предыдущем примере ожидание являются: 1) МЕТОД НАЗЫВАЕТСЯ: getAccount («Лиза») и возвращаемых значений вызываемого абонента МЕТОД: новый объект Account создал прохождение «Лиза» и «секретно» в качестве параметров конструктора

Итак, до тех пор пока теперь мне кажется, что это уже динамически создали специальный фиктивный объект и счета объекта (с установленными значениями), которые я ожидаю получить при вызове getAccount ("Lisa") способ на этом объекте. Это правильно?

Теперь у меня есть первое сомнение: что именно делает следующая строка?

replay(accountRepository); 

Это вызов только для того, чтобы сделать объект Mock доступным?

1. Затем я выполнить испытание на части подлинности() способа класса AuthenticatorImpl. Если assertTrue (res); верните мне «зеленую планку», тест пройден.

2. Убедитесь, фиктивные ожидания были встречены линии:

   проверить (accountRepository);

ОК ... но что именно эта линия делает? Потому что я думаю, что то, что говорят, если единичный тест передан («зеленый бар») или не прошел («красная полоса»), является результатом предыдущего утверждения, почему конец теста вызывает это verify() метод и передача его насмешливый объект? что делает этот метод?

Tnx

Answer 1

Использование EasyMock вы обычно делаете следующее: в первую очередь создать свой макет. Затем запишите ожидаемое поведение и, если необходимо, return/exceptions/..., вы добавите свой макет в режим воспроизведения. То есть вы сообщите EasyMock, что вы сделали запись, и теперь, если вы вызываете метод на ваш макет, вы действительно хотите зарегистрированное поведение. Затем вы будете использовать бизнес-логику для тестирования. После этого вы делаете свои утверждения и убедитесь, что ожидаемое поведение (вызов ваших методов mocks) было правильно выполнено вашей бизнес-логикой, вызвав проверку.

Answer 2

Теперь у меня есть первое сомнение: что именно делает следующая строка?

replay(accountRepository); 

Есть 2 этапа в жизни фиктивного объекта:

1. настройки ожидания
2. , осуществляемого

replay(mockObject) вызов перемещает макет из одной стадии в другой.

Потому что я считаю, что то, что говорят, если тест блок передается («зеленая полоса») или не прошел («красная полоса») является результатом предыдущего утверждают, почему тест конец callung это проверить() и передавая ему объект ? что делает этот метод?

Это неправильно. Недостаточно только assertTrue (res), чтобы определить, был ли тест успешным.

Используя ваш пример, представьте, что аутентификатор возвращает ожидаемый результат при вызове, например authenticator.authenticate(“lisa”, “secret”), но без внутреннего вызова репозитория. Если тест пройдет? Нет, и это то, что вы проверяете с помощью replay(accountRepository).