Mockito предпочтительнее EasyMock?

Недавно я переключился на фреймворк Mockito и очень им доволен (см. Также сообщение в блоге). Переход с EasyMock на Mockito был очень простым, и мне удалось сделать тесты совместимыми (т.е. тестовые примеры ведут себя одинаково).

Видите ли вы реальные причины или критерии перестрелки, чтобы предпочесть EasyMock Mockito? Пока что из кодовой базы, с которой я работал, я не могу, но меня интересует ваша точка зрения.


java unit-testing mocking mockito easymock
person manuel aldana    schedule 27.06.2010    source источник
comment
Возможный дубликат stackoverflow.com/ questions / 22697 /   -  person Raedwald    schedule 22.10.2013

Ответы (4)


arrow_upward
23
arrow_downward

Mockito был разработан для модульного тестирования в стиле BDD, а именно:

  • Учитывая (контекст, в котором выполняется ваш модульный тест)
  • Когда (события, вызывающие интересующее вас поведение)
  • Затем (результат, который вы ищете).

в отличие от

  • Данный
  • Ожидайте (вот где выполняется проверка)
  • Когда
  • Затем (вернитесь и посмотрите, что вы написали в Expect, потому что здесь нет актуальной информации).

IMHO, он производит более удобочитаемые тесты и позволяет вам разделять такие вещи, как контекст, в котором вы работаете (настройка Mocks) и проверка поведения, которое вас интересует. Предыдущие фреймворки mocking требовали, чтобы вы настраивали ожидания для каждого взаимодействия, независимо от того, относилось ли оно к аспекту поведения, на который вы смотрели в этом тесте, или нет.

person Lunivore    schedule 28.06.2010
comment
это неправда, вам не нужно «устанавливать ожидания для каждого взаимодействия». С Easymock вы можете просто настроить NiceMock (createNiceMock ()). В любом случае, я думаю, что тестирование взаимодействия с объектами - хорошая идея (и должно быть стандартным / обычным поведением) .. Я редко использую niceMocks - person mickthompson; 28.06.2010
comment
Изначально Mockito был ответвлением EasyMock до того, как появился NiceMock. В BDD это не тесты - просто описание поведения с некоторыми примерами использования класса. Идея BDD состоит в том, чтобы сделать изменение простым и безопасным, а не закреплять код, чтобы он не сломался. Тесты - хороший побочный продукт. В этом мире тестирование каждого взаимодействия не имеет такого большого смысла, как создание удобочитаемых и легко изменяемых примеров. - person Lunivore; 28.06.2010
comment
Я хочу протестировать свой код ... тогда, если он читабельный и легко изменяемый, это совсем другая история ... Я не думаю, что эксперты TDD подтвердят, что «взаимодействие не имеет большого смысла». Вы всегда получаете что-то из взаимодействия компонентов ... Я предпочитаю иметь что-то менее читаемое, но проверять правильные взаимодействия .. ИМХО взаимодействие (как читаемый / легко изменяемый код) является основной темой в тестировании и не должно не избежать так легко - person mickthompson; 28.06.2010
comment
Я не думаю, что эксперты TDD обязательно должны быть экспертами BDD. Я также никогда не говорил, что взаимодействие не имеет большого смысла - пожалуйста, прочтите формулировку, которую я использовал на самом деле, и рассмотрите контекст. - person Lunivore; 28.06.2010
comment
Я просто хотел указать, что Mockito - не единственный фреймворк, который может создавать заглушки. Я просто думаю, что взаимодействия БОЛЕЕ / ТАК актуальны, как читаемый код. Этот парень здесь, martinfowler.com/articles/mocksArentStubs.html, и другие здесь amazon.co.uk/Growing-Object-Oriented-Software-Guided-Signature/ также используют взаимодействие для стимулирования своего развития. - person mickthompson; 28.06.2010
comment
Если бы я уже написал книгу BDD с Дэном Нортом, вы бы мне больше доверяли? ;) Вот пример BDD. У нас есть контроллер, который проверяет перед отправкой в ​​репозиторий. Один пример касается проверки. Другой касается сохранения через репозиторий. У нас есть два примера, демонстрирующих эти два аспекта поведения. С Mockito нам не нужно было проверять валидацию для примера, показывающего, что мы сохранили элемент, что помогло разработчикам, не знакомым с кодом, понять, что он делает. Имеет ли это смысл? Мы пишем тесты только для того, чтобы изменения были безопасными, иначе мы могли бы протестировать вручную. - person Lunivore; 28.06.2010
comment
Мне очень нравится определение xunitpatterns.com/Test%20Double.html, которое делает тест -аспект очень ясный. Я использую Mockito для Test-Stubs, Test-Mocks и Test-Spy. Я использую средний / прагматичный путь написания тестов, они должны быть легкими в написании, но также должны что-то тестировать (чтобы избежать «ложноотрицательных» результатов тестов). Конечно, easymock (без использования nice-mocks) более строгий и теоретически более правильный, но он создает множество запутанных тестовых примеров. на мой взгляд, внутри тестовых примеров этап проверки должен быть последним и не смешиваться с настройкой (например, «ожидать» в easymock). - person manuel aldana; 28.06.2010
comment
Мне нравится это определение, но (поскольку BDD частично основан на NLP) я предпочитаю называть его Mock: имитация, обычно с коннотацией, что это одно из более низкого качества (wiktionary.org). Я называю их так, не особо беспокоясь о том, настраивают ли они контекст, проверяют результаты, кодируют вручную или используют фреймворк, потому что это подходящее английское слово, а мне нравится английский. Деловых людей иногда пугает словесный тест или идея, что им, возможно, придется его провести. Тем не менее, они понимают пример или сценарий и не имеют проблем с их предоставлением. - person Lunivore; 28.06.2010
comment
Итак ... это ответ на stackoverflow.com/questions/6177296/ просто это невозможно сделать в EasyMock? - person ripper234; 31.05.2011

arrow_upward
7
arrow_downward

Я больше знаком с EasyMock, чем с Mockito, поэтому пришлось немного покопаться. В Mockito есть страница, на которой выполняется явное сравнение с точки зрения Mockito.

На мой взгляд, преимущества Mockito заключаются в следующем:

  • Явное разделение заглушки и проверки
  • Матчеры основаны на Hamcrest (также поддерживаемом JUnit) вместо пользовательского API.
  • Созданные моки всегда «красивы»; то есть вызовы методов, которые не заблокированы, возвращают чистые данные (например, пустой список) вместо сбоя

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

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

Я бы посоветовал выбрать тот стиль, который соответствует вашим требованиям к тестированию.

Надеюсь это поможет!

person mlschechter    schedule 27.06.2010

arrow_upward
6
arrow_downward

Mockito сейчас может быть лучше, чем когда я последний раз пробовал его, но он потерял меня, когда изменил свой API, чтобы он был несовместим с предыдущими версиями. Обновление до последней версии потребовало бы от меня изменения многих из моих существующих модульных тестов, что я счел неприемлемым. Я решил, что он слишком незрелый и нестабильный для моих нужд.

Однако это не значит, что с этим что-то не так. Версия, которую я использовал, по-прежнему работает нормально, хотя с тех пор я снова переключился на EasyMock.

person Brandon Yarbrough    schedule 27.06.2010
comment
Я могу представить, что это было болезненно. В моем случае я начал с версии 1.8.3. Глядя на примечания к выпуску, кажется, что API стабилизировался. - person manuel aldana; 28.06.2010

arrow_upward
1
arrow_downward

Вот журналистский взгляд.

Случай для Mockito: http://code.google.com/p/mockito/wiki/MockitoVSEasyMock

Чехол для EasyMock: http://blog.octo.com/en/easymock-facts-fallacies/

person Barett    schedule 22.10.2013