Какой самый лучший макет фреймворка для Java?

У меня был хороший успех, используя Mockito .

Когда я попытался узнать о JMock и EasyMock, я обнаружил, что кривая обучения немного крута (хотя, возможно, это только я).

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

Вот (сокращенный) пример с главной страницы Mockito:

import static org.mockito.Mockito.*;

List mockedList = mock(List.class);
mockedList.clear();
verify(mockedList).clear();

Это не становится намного проще, чем сейчас.

Единственный серьезный недостаток, который я могу придумать, это то, что он не будет издеваться над статическими методами.

Я создатель PowerMock, так что, очевидно, я должен рекомендовать это! :-)

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

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

Сайт проекта JMockit содержит большое количество сравнительной информации для текущих наборов инструментов издевательства.

В частности, проверьте матрицу сравнения функций , которая охватывает EasyMock, jMock, Mockito, Unitils Mock, PowerMock и, конечно же, JMockit. Я стараюсь держать его точным и up-to-date, насколько это возможно.

У меня был успех с 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.

Вы также можете посмотреть на тестирование с помощью Groovy. В Groovy вы можете легко имитировать интерфейсы Java с помощью оператора 'as':

def request = [isUserInRole: { roleName -> roleName == "testRole"}] as HttpServletRequest 

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

http://docs.codehaus.org/display/GROOVY/Groovy + издевается

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

Еще одна приятная вещь заключается в том, что интерфейсы и классы реализации обрабатываются одинаково, в отличие от EasyMock, где все еще нужно помнить (и проверять), чтобы использовать расширение класса EasyMock.

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

Для меня Mockito попадает в сладкое место, будучи легким для написания и чтения, и имея дело с большинством ситуаций, которые потребует большинство кода. Использование Mockito с PowerMock было бы моим выбором.

Следует учитывать, что инструмент, который вы выбрали бы, если бы разрабатывали самостоятельно или в небольшой сплоченной команде, может быть не лучшим для большой компании с разработчиками разного уровня квалификации. Читабельность, простота использования и простота в последнем случае потребовали бы большего внимания. Нет никакого смысла в том, чтобы получить окончательный фреймворк для насмешек, если многие люди в конечном итоге не используют его или не поддерживают тесты.

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

Я использовал JMock рано. Я пробовал Mockito в своем последнем проекте, и мне это понравилось. Более лаконичный, более чистый. PowerMock охватывает все потребности, которые отсутствуют в Mockito, такие как глумление над статическим кодом, глумление над созданием экземпляра, глумление над конечными классами и методами. Так что у меня есть все необходимое для выполнения своей работы.

Мне нравится JMock, потому что вы умеете создавать ожидания. Это полностью отличается от проверки, был ли вызван метод, найденный в некоторых макетных библиотеках. Используя JMock, вы можете написать очень сложные ожидания. См. чит-шит jmock .

Да, Mockito-это отличный фреймворк. Я использую его вместе с hamcrest и Google guice для настройки моих тестов.

Лучшее решение для издевательств - это заставить машину выполнять всю работу с автоматизированным тестированием на основе спецификаций. Для Java см. ScalaCheck и структуру Reductio , включенную в функциональную библиотеку 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 реализация тех же самых концепций.

Mockito также предоставляет возможность выбора методов stubbing, сопоставления аргументов (например, anyInt() и anyString()), проверки количества вызовов (times(3), atLeastOnce(), never()) и многое другое .

Я также обнаружил, что Mockito-это просто и чисто .

Одна вещь, которая мне не нравится в Mockito, это то, что вы не можете заглушить статические методы .

Для чего-то немного другого вы могли бы использовать JRuby и Mocha , которые объединены в JtestR , чтобы написать тесты для вашего кода Java в выразительном и сжатом Ruby. Здесь есть несколько полезных насмешливых примеров с JtestR . Одно из преимуществ этого подхода заключается в том, что насмешка над конкретными классами очень проста.

Я начал использовать mocks через JMock, но в конечном итоге перешел на использование EasyMock. EasyMock было именно так-проще - и обеспечивало синтаксис, который казался более естественным. С тех пор я ни разу не менялся.