Java в примерах для начинающих
В статье о тестировании параметров при помощи 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!