Какая лучшая структура для создания mock-объектов в Java? Зачем? Каковы преимущества и недостатки каждой структуры?
Какая лучшая фреймворк для Java?
Ответ 1
У меня был хороший успех, используя Mockito.
Когда я попытался узнать о JMock и EasyMock, я обнаружил, что кривая обучения немного крута (хотя, возможно, это только я).
Мне нравится Mockito из-за его простого и чистого синтаксиса, который я смог схватить довольно быстро. Минимальный синтаксис разработан, чтобы поддерживать общие случаи очень хорошо, хотя несколько раз мне нужно было сделать что-то более сложное, я нашел то, что я хотел, было поддержано и легко понять.
Здесь (сокращенный) пример с домашней страницы Mockito:
import static org.mockito.Mockito.*;
List mockedList = mock(List.class);
mockedList.clear();
verify(mockedList).clear();
Это не намного проще.
Единственным серьезным недостатком, о котором я могу думать, является то, что он не будет издеваться над статическими методами.
Ответ 2
Я создатель PowerMock, поэтому я должен рекомендовать это!: -)
PowerMock расширяет и EasyMock и Mockito с возможностью mock статические методы, окончательные и даже частные методы. Поддержка EasyMock завершена, но плагин Mockito нуждается в дополнительной работе. Мы также планируем добавить поддержку JMock.
PowerMock не предназначен для замены других фреймворков, скорее он может использоваться в сложных ситуациях, когда другие фреймворки не позволяют насмехаться. PowerMock также содержит другие полезные функции, такие как подавление статических инициализаторов и конструкторы.
Ответ 3
сайт проекта JMockit содержит большое количество сравнительной информации для текущих надуманных наборов инструментов.
В частности, проверьте матрицу сравнения функций, которая охватывает EasyMock, jMock, Mockito, Unitils Mock, PowerMock, и, конечно же, Дж.Моккита. Я стараюсь держать его точным и современным, насколько это возможно.
Ответ 4
У меня был успех с JMockit.
Это довольно новый, и поэтому он немного сырой и недостаточно документированный. Он использует ASM для динамического переопределения байт-кода класса, поэтому он может издеваться над всеми методами, включая статические, частные, конструкторы и статические инициализаторы. Например:
import mockit.Mockit;
...
Mockit.redefineMethods(MyClassWithStaticInit.class,
MyReplacementClass.class);
...
class MyReplacementClass {
public void $init() {...} // replace default constructor
public static void $clinit{...} // replace static initializer
public static void myStatic{...} // replace static method
// etc...
}
В нем есть интерфейс ожиданий, позволяющий записывать и записывать сценарии:
import mockit.Expectations;
import org.testng.annotations.Test;
public class ExpecationsTest {
private MyClass obj;
@Test
public void testFoo() {
new Expectations(true) {
MyClass c;
{
obj = c;
invokeReturning(c.getFoo("foo", false), "bas");
}
};
assert "bas".equals(obj.getFoo("foo", false));
Expectations.assertSatisfied();
}
public static class MyClass {
public String getFoo(String str, boolean bool) {
if (bool) {
return "foo";
} else {
return "bar";
}
}
}
}
Недостатком является то, что для него требуется Java 5/6.
Ответ 5
Вы также можете посмотреть тестирование с помощью Groovy. В Groovy вы можете легко высмеять интерфейсы Java с помощью оператора "as":
def request = [isUserInRole: { roleName -> roleName == "testRole"}] as HttpServletRequest
Помимо этой базовой функциональности Groovy предлагает намного больше на издевательском фронте, включая мощные классы MockFor и StubFor.
Ответ 6
Я начал использовать mocks с EasyMock. Достаточно легко понять, но шаг повторения был довольно раздражающим. Mockito удаляет это, также имеет более чистый синтаксис, поскольку он выглядит так, как читаемость была одной из его основных целей. Я не могу достаточно подчеркнуть, насколько это важно, поскольку большинство разработчиков тратят свое время на чтение и поддержание существующего кода, а не на его создание.
Еще одна приятная вещь: интерфейсы и классы реализации обрабатываются таким же образом, в отличие от EasyMock, где вам еще нужно запомнить (и проверить) использование расширения класса EasyMock.
Недавно я быстро просмотрел JMockit, и пока список функций для стирки довольно всеобъемлющий, я думаю, что цена на это - разборчивость полученного кода и необходимость писать больше.
Для меня Мокито попадает в сладкое место, будучи легким в написании и чтении, и имеет дело с большинством ситуаций, которые потребуются большинству кода. Используя Mockito с PowerMock будет моим выбором.
Одна вещь, которую следует учитывать, - это то, что инструмент, который вы бы выбрали, если бы вы разрабатывали самостоятельно или в небольшой сплоченной команде, может оказаться не лучшим для крупной компании с разработчиками разных уровней квалификации. Читаемость, простота использования и простота в последнем случае потребуют большего внимания. Нет смысла получать окончательную насмешливую структуру, если многие люди не используют ее или не поддерживают тесты.
Ответ 7
Мы активно используем EasyMock и расширение класса EasyMock на работе и очень довольны этим. Это в основном дает вам все, что вам нужно. Взгляните на документацию, там очень хороший пример, который показывает вам все функции EasyMock.
Ответ 8
Раньше я использовал JMock. Я пробовал Mockito в своем последнем проекте и мне понравилось. Более кратким, более чистым. PowerMock покрывает все потребности, отсутствующие в Mockito, такие как издевательствование статического кода, издевка над созданием экземпляра, высмеивание окончательных классов и методов. Поэтому у меня есть все, что нужно для выполнения моей работы.
Ответ 9
Мне нравится JMock, потому что вы можете настроить ожидания. Это полностью отличается от проверки того, был ли метод вызван найденным в некоторых макетных библиотеках. Используя JMock, вы можете написать очень сложные ожидания. См. Jmock cheat-sheat.
Ответ 10
Да, Mockito - отличная рамка. Я использую его вместе с hamcrest и Google настройте мои тесты.
Ответ 11
Лучшим решением для насмешек является то, чтобы машина выполняла всю работу с автоматическим тестированием на основе спецификации. Для Java см. ScalaCheck и Reductio рамки, включенные в библиотеку Functional Java. С автоматизированными основами тестирования на основе спецификаций вы предоставляете спецификацию тестируемого метода (свойство, которое должно быть истинным), и среда автоматически генерирует тесты, а также макеты.
Например, следующее свойство проверяет метод Math.sqrt, чтобы увидеть, равен ли квадратный корень любого положительного числа n в квадрате n.
val propSqrt = forAll { (n: Int) => (n >= 0) ==> scala.Math.sqrt(n*n) == n }
Когда вы вызываете propSqrt.check(), ScalaCheck генерирует сотни целых чисел и проверяет ваше свойство для каждого, а также автоматически, чтобы убедиться, что края дела хорошо покрыты.
Несмотря на то, что ScalaCheck написан на Scala и требует компилятора Scala, легко проверить код Java с ним. Структура Reductio в функциональной Java является чистой реализацией Java с теми же концепциями.
Ответ 12
Mockito также предоставляет возможность методов stubbing, сопоставляя аргументы (например anyInt() и anyString()), проверяя количество invocations (times (3), atLeastOnce(), never()), и более.
Я также обнаружил, что Mockito прост и чист.
Одна вещь, которая мне не нравится в Mockito, заключается в том, что вы не можете ставить статические методы.
Ответ 13
Для чего-то немного другого, вы можете использовать JRuby и Mocha, которые объединены в JtestR для написания тестов для вашего Java-кода в выразительном и сжатом Ruby. Есть несколько полезных издевательских примеров с JtestR здесь. Одним из преимуществ этого подхода является то, что издевательские конкретные классы очень просты.
Ответ 14
Я начал использовать mocks через JMock, но в итоге перешел на использование EasyMock. EasyMock был именно таким, - более простым - и обеспечивал синтаксис, который казался более естественным. С тех пор я не переключался.