Собственные матчеры аргументов.

В статье о тестировании параметров при помощи EasyMock рассказывалось про использование матчеров аргументов, позволяющих гибко описывать входные параметры вызываемых из тестируемого кода методов, а также приводился их список. Разумеется, список матчеров не конечный и EasyMock допускает разработку собственных матчеров. Предположим, Читать далее Собственные матчеры аргументов.

Генерация ответов во время тестирования

Использование EasyMock подразумевает статическую генерацию ответов из expect(), когда уже на стадии написания теста известно, что вернёт метод и какие будут его значения. На случай, если этого недостаточно, в EasyMock предусмотрено два вызова, позволяющих создавать возвращаемый из mock-объекта результат во Читать далее Генерация ответов во время тестирования

Как написать собственный hamcrest matcher

Hamcrest содержит прекрасную библиотеку матчеров, а их комбинирование позволяет творить чудеса.  А когда их возможностей не хватает, можно написать свой собственный матчер. Мне потребовалось проверять результат формирования параметров GET запроса:

И я столкнулся с тем, что во-первых это строка, Читать далее Как написать собственный hamcrest matcher

Как сделать тесты JodaTime переносимыми

Многие функции JodaTime оперируют с текущим временным поясом. Это хорошо и для приложения, которое автоматически работает с временем корректно и для разработчика, которому не надо писать эту корректность. Но в юнит-тестах «текущий» временной пояс является неопределённым параметром окружения и может вызывать Читать далее Как сделать тесты JodaTime переносимыми

Захват аргументов

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

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

Тестирование параметров

В статье о тестировании поведения было написано буквально пару слов о сравнении фактических аргументов методов с ожидаемыми. Пришло время рассказать о этом механизме подробнее. Stub mocks и pattern matching Не совсем корректно называть то, о чем я сейчас напишу «pattern Читать далее Тестирование параметров

Тестирование поведения

В предыдущих статьях о EasyMock все тесты были написаны в стиле чёрного ящика: проверялось что функция возвращает определённый результат для заданных значений, а как она эта делает, никого не интересует. Mock-объекты использовались как средство изоляции кода и не более того. Читать далее Тестирование поведения

EasyMock mocks: nice, default, strict, stub и partial

В ознакомительном примере EasyMock, я писал: «в аннотации @Mock я указал, что хочу так называемый “nice mock”. На самом деле, аннотация @Mock(type = MockType.NICE) создает full nice non-strict mock, что означает «mock с подменой всех методов, поведением по умолчанию и без проверки порядка вызовов». Читать далее EasyMock mocks: nice, default, strict, stub и partial

Всё вместе: easymock и параметризованные тесты

Когда я писал статьи по JUnit, мой коллега спросил меня, а могу ли я привести пример использования продвинутого функционала JUnit, например параметризованных тестов, в дикой природе его коде, c использованием mock объектов, внедрения зависимостей итд. Пришлось показывать 🙂 Я не могу поделиться Читать далее Всё вместе: easymock и параметризованные тесты

Внедрение зависимостей в EasyMock

Если зависимости в ваш код внедряются через конструктор или через сеттеры, использование EasyMock очевидно: создаём mock и передаём его в тестируемый object. А если зависимости внедряются напрямую в поля класса, EasyMock связывает их автоматически 🙂 Возьмём код примера Hello, EasyMock и добавим Читать далее Внедрение зависимостей в EasyMock