Что мне делает насмешливый фреймворк?

Question

Я слышал, что некоторые люди, с которыми я не могу поговорить, являются большими поклонниками jmock.Я занимался разработкой, ориентированной на тестирование, в течение многих лет, поэтому я просмотрел веб-сайт и посмотрел некоторые документы и до сих пор не могу понять, насколько он хорош.

У меня была такая же проблема с весной.Их документы отлично справляются, объясняя это, если вы уже понимаете, что это такое, поэтому я не предполагаю, что jmock не представляет никакой ценности.Я просто не понимаю, что это делает для меня.

Так что, если jmock предоставляет мне возможность смоделировать заглушки, давайте рассмотрим пример того, как я делаю вещи, и посмотрим, как jmock будет лучше.

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

Когда я пишу свои тесты, вот как я это делаю.

Во-первых, я заново указываю гибернацию на свою тестовую гиперзвуковую базу данных, поэтому мне не нужно настраивать базу данных.,Hibernate создает мои таблицы для меня.

Все мои тесты для моих классов имеют статические фабричные методы, которые создают для меня тестовый экземпляр класса.Каждый из моих DAO создает тестовые версии, которые указывают на схему тестирования.Тогда у моего класса обслуживания есть тот, который конструирует себя с DAO, сгенерированными тестовым классом.

Теперь, когда я запускаю тест контроллера UI, который вызывает сервис, я тестирую свой код на всем протяжении приложения.Конечно, это не тотальный уровень изоляции, который обычно требуется при выполнении модульного теста, но, на мой взгляд, он дает мне лучший модульный тест, поскольку он выполняет реальный код на всех уровнях поддержки.

Поскольку Hypersonic в режиме гибернации работает медленно, выполнение всех моих тестов занимает немного больше времени, но вся моя сборка все еще выполняется менее чем за пять минут на старом компьютере для полной сборки и упаковки, поэтому я нахожу это вполне приемлемым.

Как бы я поступил по-другому с jmock?

Answer 1

В вашем примере есть два интерфейса, в которых один будет использовать макетную среду для выполнения правильных модульных тестов:

• Интерфейс между уровнем пользовательского интерфейса и службой виджетов - замена службы виджетов наmock позволит вам тестировать уровень пользовательского интерфейса изолированно, при этом служба будет возвращать данные, созданные вручную, а mock проверять, что ожидаемые вызовы службы (и никаких других) происходят.
• Интерфейс между службой виджетов и DAO- путем замены DAO на макет, любые сервисные методы, которые содержат сложную логику, можно тестировать изолированно.

Разумеется, это не полная изоляция, которая обычно требуется при выполнении модульного теста,но, на мой взгляд, он дает мне лучший модульный тест, поскольку он выполняет реальный код на всех уровнях поддержки.

Похоже, в этом суть вашего вопроса.Ответ имеет несколько аспектов:

• Если вы не тестируете компоненты изолированно, у вас нет модульных тестов, у вас есть интеграционные тесты.Как вы заметили, это весьма ценно, но у них есть свои недостатки
• Так как они тестируют больше вещей одновременно, они имеют тенденцию ломаться чаще, они имеют тенденцию разбиваться в большие группы (когда есть проблема собщей функциональности), и когда они это делают, труднее выяснить, в чем заключается реальная проблема
• Они более ограничены в том, какие сценарии можно тестировать.Может быть трудно или невозможно смоделировать определенные крайние случаи в интеграционном тесте.
• Иногда полный интеграционный тест не может быть автоматизирован, потому что для настройки какого-либо компонента недостаточно контроля (например, стороннего веб-сервиса)данные теста вам нужны.В таком случае вы можете даже использовать фальшивый фреймворк в том, что в противном случае является интеграционным тестом высокого уровня.

Answer 2

В частности, я не рассматривал JMock (я использую Mockito), но в целом фреймворк-фреймворки позволяют вам «имитировать» внешние сервисы, так что вам нужно тестировать только один класс за раз.Любые зависимости этого класса можно смоделировать, то есть реальные вызовы методов не выполняются, и вместо этого вызываются заглушки, которые возвращают или генерируют константы.Это хорошо, потому что внешние вызовы могут быть медленными, непоследовательными или ненадежными - все это плохо для модульного тестирования.

Чтобы привести один пример того, как это работает, представьте, что у вас есть класс обслуживания, который имеетзависимость от клиента веб-службы.Если вы тестируете с реальным клиентом веб-службы, он может быть неработающим, соединение может быть медленным или данные за веб-службой могут со временем меняться.Как вы собираетесь написать надежный тест против этого?(Вы не можете).Таким образом, вы используете фиктивный фреймворк для макетирования / заглушки клиента веб-службы и создаете фальшивые ответы, фальшивые ошибки, фальшивые исключения, чтобы имитировать поведение веб-сервиса.Разница в том, что результат всегда быстрый и непротиворечивый.

Кроме того, вы хотели бы протестировать все случаи сбоев, которые может иметь данная зависимость, но без насмешек это сложно сделать.Рассмотрим пример, который я привел выше.Вы хотите быть уверены, что ваш код работает правильно, если веб-служба выдает IOException, потому что веб-служба не работает (или время ожидания истекло), но это условие не так легко вызвать.С насмешками это становится тривиальным.