Сравнение между Mockito и JMockit-почему Mockito проголосовал лучше, чем JMockit? [закрытый]

Я бы сказал, что конкуренция между JMockit и PowerMock, потом Mockito.

Я бы оставил "простой" jMock и EasyMock, потому что они используют только proxy & CGLIB и не используют инструментарий Java 5, как новые фреймворки.

jMock также не имел стабильного выпуска более 4 лет. jMock 2.6.0 потребовалось 2 года, чтобы перейти от RC1 к RC2, а затем еще 2 года, прежде чем он фактически был выпущен.

в отношении Proxy & CGLIB vs instrumentation:

(EasyMock и jMock) основаны на java.ленг.отражать.Полномочие, что требует интерфейс выполненный. Кроме того, они поддержка создания макетов объектов для классов через подкласс CGLIB поколение. Из-за этого, сказал классы не могут быть окончательными и только переопределяемые методы экземпляра могут быть издевавшийся. Однако самое главное, при использовании этих инструментов зависимости тестируемого кода (что есть объекты других классов на данного тестируемого класса зависит) должно быть проконтролировано тесты, чтобы имитировать экземпляры передано клиентам тех зависимости. Поэтому зависимости нельзя просто создать экземпляр с помощью новый оператор в классе клиента для которые мы хотим написать модульные тесты.

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

1. каждый класс, который может потребоваться высмеять в тесте, должен либо реализовать отдельный интерфейс или не быть окончательным.
2. зависимости каждого тестируемого класса должны быть получены создание настраиваемого экземпляра методы (фабрики или сервис Locator), или быть подверженным зависимости инъекция. В противном случае модульные тесты не будут возможность передачи макетных реализаций зависимости от единицы измерения тест.
3. так как только экземпляр методы могут быть высмеяны, классы для модульного тестирования невозможно вызвать статические методы их зависимости, ни инстанцировать их использует любой из конструкторов.

выше скопировано из http://jmockit.org/about.html . Кроме того, он сравнивает между собой (JMockit), PowerMock и Mockito несколькими способами:

теперь есть другие насмешливые инструменты для Java, который также преодолевает ограничения обычных те, между ними PowerMock, jEasyTest, и MockInject. Тот, что ближе всего для набора функций JMockit PowerMock, поэтому я кратко оценю он здесь (кроме того, два других более ограниченный и не кажущийся активно развивается).

JMockit vs PowerMock

• прежде всего, PowerMock не предоставляет полный API для насмешек, но вместо этого работает как расширение другой инструмент, который в настоящее время может быть EasyMock или Mockito. Это очевидно преимущество для существующих пользователей этот инструмент.
• JMockit, с другой стороны, предоставляет совершенно новые API, хотя его основной API (ожидания) похож как jMock и EasyMock. Пока это создает более длинную кривую обучения, также позволяет JMockit обеспечить проще, последовательнее и проще использовать API.
• по сравнению с API ожиданий JMockit, API PowerMock больше "низкого уровня", заставляя пользователи выясните и укажите, какие классы необходимо быть готовым к тестированию (с @PrepareForTest ({ClassA.класс, ...}) аннотация) и требование конкретные вызовы API для работы различные виды языковых конструкций что может присутствовать в продукции код: статические методы (mockStatic (ClassA.класс)), проектировщики (suppress (конструктор (ClassXyz.класс))), вызовы конструкторов (expectNew (AClass.класс)) частичная mocks (createPartialMock (ClassX.класс, "methodToMock")) и др.
• С ожиданиями JMockit, все виды методов и конструкторов издевались чисто декларативно, с частичным насмешливый указано регулярные выражения в @Mocked аннотация или просто " un-mocking" члены не записали ожидания; то есть разработчик просто объявляет некоторые общие " mock поля " для тестового класса или некоторых "местные макет поля" и/или "глумиться параметры " для индивидуального испытания методы (и в в этом последнем случае @ Mocked аннотация часто не будет необходимый.)
• некоторые возможности, доступные в JMockit, такие как поддержка насмешек равно и хэш-код, переопределен методы, и другие, в настоящее время не поддерживается в PowerMock. Кроме того, есть нет эквивалента способности JMockit захват экземпляров и макет реализации указанной базы типы по мере выполнения теста, без сам тестовый код имеет любой знание фактического осуществления занятия.
• PowerMock использует пользовательские загрузчики классов (обычно по одному на тестовый класс) для генерации измененных версий из высмеянных классов. Такое тяжелое использование пользовательских загрузчиков класса может привести к конфликты со сторонними библиотеками, следовательно, необходимо иногда использовать @PowerMockIgnore (пакет".для.быть.игнорируется") аннотация по тестовым классам.
• механизм, используемый JMockit (инструментарий времени выполнения через "Java agent") проще и безопаснее, несмотря на то это требует прохождения параметр" - javaagent " для JVM, когда разработка на JDK 1.5; на JDK 1.6+ (который всегда можно использовать для разработка, даже если развертывание на старая версия) нет такого требование, так как JMockit может прозрачно загрузите агент Java спрос с помощью API-интерфейса Attach.

еще один недавний насмешливый инструмент Mockito. Хотя и не пытается преодолеть ограничения старших инструменты (jMock, EasyMock), он делает ввести новый стиль поведения тестирование с насмешками. JMockit также поддерживает этот альтернативный стиль, через проверку через API.

JMockit vs Mockito

• Mockito полагается на явные вызовы своего API для разделения кода между записью (когда(...)) и проверить (verify(...)) фазы. Этот означает, что любое обращение к mock объект в тестовом коде также потребует вызов насмешливого API. Кроме того, это часто приводит к повторения(...) и проверка (макет)... звонки.
• С JMockit подобных вызовов не существует. Конечно, у нас есть новый NonStrictExpectations () и новые Проверок() вызова конструктора, но они происходят только один раз за тест (типично), и вполне отдельно от призывов к издевались над методами и конструкторами.
• API Mockito содержит несколько несоответствий в синтаксисе, используемом для призывы к издевательским методам. В запись фазы, мы есть такие звонки, как когда (насмешка.mockedMethod (args))... в то время как на этапе проверки этот же вызов будет записано как проверка (макет).mockedMethod (args). Обратите внимание, что в первом случае сделано обращение к mockedMethod непосредственно на макет объекта, в то время как в второй случай сделан на объект, возвращаемый verify (макет).
• JMockit не имеет таких несоответствий, потому что вызовы глумились методы всегда непосредственно на издевавшихся экземплярах сами себя. (За одним исключением: чтобы сопоставить вызовы на то же самое высмеянный экземпляр, onInstance(макет) вызов используется, в результате чего код, как onInstance(макет).mockedMethod (args); большинство тестов не должны использовать это, хотя.)
• как раз как другие издеваясь инструменты которые полагаются на методе цепочка / упаковка, Mockito также работает в непоследовательный синтаксис при stubbing методы пустоту. Например, вы пишете когда (mockedList.get (1)).thenThrow (новый RuntimeException ()); для непустого метод и doThrow (новый RuntimeException ()).когда(mockedList).четкий(); для пустоты. С JMockit, это всегда один и тот же синтаксис: mockedList.clear (); result = новый RuntimeException();.
• еще одна непоследовательность возникает при использовании шпионов Mockito: "издевается" что давали реальных методов выполняется на шпионском экземпляре. Для пример, если spy ссылается на пустой Список, а затем вместо написания когда(шпион.get (0)).thenReturn("Фу") Вы нужно будет написать доретурн ("фу").когда(шпион).get (0). С JMockit, динамический насмешливая характеристика предоставляет аналогичную функциональность шпионы, но без этого вопроса с тех пор реальные методы выполняются только во время этап Replay.
• в EasyMock и jMock, первых издевательских API для Java, фокус был полностью на записи ожидаемого призывы насмешливых методов, для макет объектов, которые (по умолчанию) не разрешить неожиданные вызовы. Те API также обеспечивают запись разрешенные вызовы для макетных объектов которые позволяют неожиданные вызовы, но к этому относились как ко второму классу. особенность. Дополнительно, с этими инструменты нет способа явно проверьте вызовы к mocks после тестируемый код выполняется. Все такие проверки выполняются неявно и автоматически.
• в Mockito (а также в Unitils Mock) противоположная точка зрения взятый. Все вызовы для mock объектов это может произойти во время испытания, независимо от того, записаны или нет, разрешены, не ожидать. Проверка выполняется явно после кода под испытанием осуществляется, никогда автоматически.
• оба подхода слишком экстремальны и, следовательно, менее оптимальны. Ожидания И Проверки JMockit единственный API, который позволяет разработчик легко выбрать лучшая комбинация strict (ожидается по умолчанию) и нестрогим (разрешено по умолчанию) mock invocations для каждого тест.
• чтобы быть более ясным, API Mockito имеет следующий недостаток. Если вы необходимо проверить, что вызов Non-void высмеянный метод произошел во время тест, но тест требует возвращаемое значение из этого метода отличается от значения по умолчанию для возвращаемый тип, затем тест Mockito придется дублировать код: когда (насмешка.someMethod ()).thenReturn (xyz) вызов на этапе записи и a проверка (макет).someMethod () в проверить фазу. С JMockit, строгий ожидание всегда может быть записано, не обязательно быть четко верифицированный. Альтернативно, вызов ограничение count (times = 1) может быть указано для любых записанных нестрогих ожидание (с Mockito такое ограничения могут быть указаны только в проверка (макет, ограничение) вызова).
• Mockito имеет плохой синтаксис для проверок по порядку и для полного проверки (то есть проверка того, что все вызовы mock объектов явно проверено). В первый случае дополнительный объект должен быть создано, и вызовы для проверки сделаны на это: InOrder inOrder = inOrder(mock1, mock2,...). Во втором случае, звонки как verifyNoMoreInteractions (макет) или verifyZeroInteractions (mock1, mock2) нужно что-то сделать.
• С JMockit вы просто пишете новый VerificationsInOrder () или новый FullVerifications () вместо new Проверки () (или новые FullVerificationsInOrder (), чтобы объединить оба требования.) Не нужно указывать который задействованы фиктивные объекты. Нет дополнительные насмешливые вызовы API. И как бонус, позвонив unverifiedInvocations () внутри заказанный блок проверки, вы можете выполнение проверок, связанных с заказом в Мокито это просто невозможно.

наконец, инструментарий тестирования JMockit имеет широкий охват и более амбициозные голы чем другие издевательские наборы инструментов, в порядок предоставления полного и сложное тестирование разработчиков решение. Хороший API для насмешек, даже без искусственных ограничений, не достаточно для продуктивного создания тесты. IDE-агностик, прост в использовании, и хорошо интегрированный инструмент покрытия кода также важно, что Jmockit покрытие стремится обеспечить. Еще одна часть тестирования разработчика набор инструментов, который станет более полезным по мере того как набор тестов растет в размере возможность поэтапного повторного запуска тестов после локализованного изменения производства код; это также включено в Инструмент покрытия.

(конечно, источник может быть предвзятым, но хорошо...)

Я бы сказал, пойти с JMockit. Это самый простой в использовании, гибкий и работает практически во всех случаях, даже сложных и сценариев, когда вы не можете контролировать класс для тестирования (или вы не можете сломать его из-за причин совместимости и т. д.).

мой опыт работы с JMockit был очень позитивным.