В статье о тестировании параметров при помощи EasyMock рассказывалось про использование матчеров аргументов, позволяющих гибко описывать входные параметры вызываемых из тестируемого кода методов, а также приводился их список. Разумеется, список матчеров не конечный и EasyMock допускает разработку собственных матчеров. Предположим, Читать далее Собственные матчеры аргументов.
Использование EasyMock подразумевает статическую генерацию ответов из expect(), когда уже на стадии написания теста известно, что вернёт метод и какие будут его значения. На случай, если этого недостаточно, в EasyMock предусмотрено два вызова, позволяющих создавать возвращаемый из mock-объекта результат во Читать далее Генерация ответов во время тестирования
Помимо богатых возможностей по сравнению аргументов, EasyMock позволяет подсмотреть, какой-же фактически аргумент был передан.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 | public class captureTest { @Rule public EasyMockRule em = new EasyMockRule(this); @Mock(type = MockType.DEFAULT) private GroupRepository groupRepository; @Mock(type = MockType.DEFAULT) private UserRepository userRepository; @TestSubject private UserService testedObject = new UserService(); @Test public void simpleCaptureTest() { Capture<User> actual = EasyMock.newCapture(); userRepository.save(capture(actual)); replay(userRepository); testedObject.create("TEST"); if (!actual.hasCaptured()) { fail("Save argument is not valid"); } assertThat(actual.getValue(), is(testUser())); } } |
capture() это фактически матчер, поэтому его можно использовать в связке с любыми другими матчерами. Созданный capture объект может быть использовать в нескольких вызовах, но запомнит результат Читать далее Захват аргументов
В статье о тестировании поведения было написано буквально пару слов о сравнении фактических аргументов методов с ожидаемыми. Пришло время рассказать о этом механизме подробнее. Stub mocks и pattern matching Не совсем корректно называть то, о чем я сейчас напишу «pattern Читать далее Тестирование параметров
В предыдущих статьях о EasyMock все тесты были написаны в стиле чёрного ящика: проверялось что функция возвращает определённый результат для заданных значений, а как она эта делает, никого не интересует. Mock-объекты использовались как средство изоляции кода и не более того. Читать далее Тестирование поведения
В ознакомительном примере EasyMock, я писал: «в аннотации @Mock я указал, что хочу так называемый “nice mock”. На самом деле, аннотация @Mock(type = MockType.NICE) создает full nice non-strict mock, что означает «mock с подменой всех методов, поведением по умолчанию и без проверки порядка вызовов». Читать далее EasyMock mocks: nice, default, strict, stub и partial
Когда я писал статьи по JUnit, мой коллега спросил меня, а могу ли я привести пример использования продвинутого функционала JUnit, например параметризованных тестов, в дикой природе его коде, c использованием mock объектов, внедрения зависимостей итд. Пришлось показывать 🙂 Я не могу поделиться Читать далее Всё вместе: easymock и параметризованные тесты
Если зависимости в ваш код внедряются через конструктор или через сеттеры, использование EasyMock очевидно: создаём mock и передаём его в тестируемый object. А если зависимости внедряются напрямую в поля класса, EasyMock связывает их автоматически 🙂 Возьмём код примера Hello, EasyMock и добавим Читать далее Внедрение зависимостей в EasyMock
В статьях о JUnit я использовал в качестве примеров простые самодостаточные классы, которые не имели никаких зависимостей. На практике такие классы встречаются редко: обычно класс, выполняющий хоть какие-либо действия, зависит от других классов. Примером может служить классическая архитектура с многослойными приложениями, когда один Читать далее Hello, EasyMock!