В чем разница между фреймворками PowerMock, EasyMock и Mockito? [дубликат]
этот вопрос уже есть ответ здесь:
Я очень новичок в mocking framework, и моя работа нуждается в mocking framework для завершения модульного тестирования. В коде я мог видеть выше 3 рамки используются в разных местах для блока тестирование. Так, что я должен идти в вышеприведенных 3 рамки ?
3 ответов
Я даю вам объяснение, которое другим людям, вероятно, не понравится, но я (и многие люди, которым я упомянул об этом) нашел/нашел очень полезным: Powermock-это насмешливая структура ... этим лучше не пользоваться.
главная преимущество из Powermock является то, что вы можете использовать его для тестирования определенных конструкций (например static вызовы метода), что EasyMock не может издеваться. Таким образом: когда вы хотите протестировать сторонний код, который вы не можете изменить; и который содержит статический затем вы можете обратиться к PowerMock.
но когда вы пишете свой собственный код, и вы сосредоточитесь на написания тестируемого кода; тогда вы обнаружите, что" необходимость использовать Powermock "абсолютно равна"вы плохо поработали над своим кодом". Используя static например, непосредственно ведет к прямое соединение между вашими классами; и поэтому это жесткий, чтобы избавиться от него, как только он находится.
Не поймите меня неправильно - Powermock имеет свое место в испытании; но свои мощные характеристики приходят на некоторую цену.
на EasyMock / Mokito: в основном "два разных способа" записи тестовых примеров; более поздний, ведущий к тестам, которые многие люди находят легче читать; в то время как EasyMock и "строгие" насмешки позволяют записывать тестовые случаи, которые быстро сломаются при большинстве изменений в вашем производственном коде (что само по себе может быть очень полезно или очень раздражает).
здесь вы можете найти сравнение между Mockito и EasyMock:
различия
нет режимов записи/воспроизведения-нет необходимости в них. Есть только 2 вещи, которые вы можете сделать с Mockito mocks - verify или stub. Stubbing идет перед исполнением и проверкой после этого.
все насмешки хороши (даже как-то приятнее, потому что методы возврата коллекции возвращают пустые коллекции вместо нулей). Даже хотя насмешки хороши, вы можете проверить их так строго, как хотите, и обнаружить любое нежелательное взаимодействие.
явный язык для лучшей читаемости: verify () и when () против смеси expect(mock.фу ()) и МОК.foo () (простой вызов метода без ожидания). Я уверен, что некоторые из вас найдут это субъективный аргумент :)
упрощенная модель stubbing-stubbed методы воспроизводят все время с stubbed значением независимо от того, сколько раз они называются. Работает точно так же, как andStubReturn EasyMock (в), andStubThrow(). Кроме того, вы можете заглушить разные возвращаемые значения для разных аргументов (например, в EasyMock).
проверка методов stubbed необязательна, потому что обычно более важно проверить, правильно ли используется значение stubbed, а не откуда оно взялось.
проверка явные ошибки проверки указывают на строку кода, показывающие как взаимодействие неудачный.
проверка в порядке гибка и не требует проверки каждого отдельного взаимодействия.
пользовательские сопоставители аргументов используют сопоставители hamcrest, поэтому вы можете использовать существующие сопоставители hamcrest. (EasyMock также может интегрироваться с Hamcrest, хотя он не является частью EasyMock, но Hamcrest. См. документацию Hamcrest).
PowerMock-это расширение других насмешливых фреймворков как Mockito или EasyMock, который поставляется с более мощными возможностями. Это означает, что вы можете объединить Mockito/EasyMock и PowerMock в один и тот же модульный тест.
Я лично использую Mockito для модульного тестирования большой части моего кода и PowerMock только в коде, который нуждается в дополнительных функциях в качестве статических методов тестирования.
Если вы контролируете свой дизайн, и вы должны быть в основном в порядке с Mockito. Например PowerMock позволяет издеваться над собственным членом, который выглядит круто, но не обязательно, если вы рефакторинг, что для параметра обеспечивается через внедрение зависимостей.