TestNG против Спока для автоматизации

Мы смотрим на реализацию тестового фреймворка и интересуемся, какой фреймворк использовать. Мы выбираем между TestNG и Spock. Это будет среда автоматизации пользовательского интерфейса, поэтому она должна обрабатывать как можно меньше ложных данных. Наша кодовая база будет состоять из Geb (Groovy).

При этом у Спока есть три преимущества перед TestNG:

Подробная информация Среда выполнения Спока собирает огромное количество информации и предоставляет ее вам при необходимости. Условие не выполнено:

max(a, b) == c
|   |  |  |  |
3   1  3  |  2
          false

Прекрасный язык Выразите свои мысли на красивом и очень выразительном языке спецификаций.

def "subscribers receive published events at least once"() {
    when: publisher.send(event)
    then: (1.._) * subscriber.receive(event)
    where: event << ["started", "paused", "stopped"]
}

Расширяемый для всех@Transaction? @SpringBean? @DeployApp? С помощью механизма расширений Spock, основанного на перехвате, вы можете легко создавать свои собственные расширения.

У кого-нибудь есть мнение, почему один может быть лучше другого?

Есть ли недостатки либо?

Есть ли способ создать "красивый язык" в отчетах для TestNG? По сути, я могу создать свои собственные теги и иметь программу для их анализа? Или уже есть сторонняя библиотека для добавления?

Спасибо за вашу помощь в продвинутом.

Источник

2 ответа

Для автоматизации пользовательского интерфейса взгляните на Geb, прежде чем пытаться создать новую среду. http://www.gebish.org/

Geb будет работать как со споком, так и с TestNG.

В целом, у меня был действительно хороший опыт работы со споком, но я не могу говорить с TestNG.

Хотелось бы, чтобы у spock были отчеты в стиле BDD, такие как Cucumber, и тестирование стиля свойств, например, ScalaCheck, но, поскольку это простое тестирование в стиле TDD, спок является выразительным, простым в использовании, многофункциональным и действительно хорошо разработанным. По сравнению с такими вещами, как JUnit, спок - это радость - требуется очень мало церемоний.

Источник

Я использую TestNG в течение нескольких лет, нескольких проектов, и я вполне доволен этим. Отвечая на конкретные вопросы вашего вопроса

Красивый язык

Имя метода тестирования должно быть допустимым именем метода Java. Это означает, что нет пробелов. Я начинаю свои методы с следует, поэтому я бы назвал ваш метод subscribers receive published events at least once как shouldSubscrbersReceiveEvents, Я считаю, что это короткое имя описывает намерение достаточно хорошо. Имена верблюдов не так удобны для чтения, как правильные предложения, но другого выбора нет.

Разделы с указанием, когда тогда

TestNG не имеет встроенной функции для поддержки этого. Я делаю это вручную, используя комментарии. Нет фреймворковой поддержки для таких функций, как:

  • параметры, поступающие из where: разделы. Вы можете использовать @DataProviders для этого.
  • утверждения для заявлений в then: раздел. Вы должны написать утверждения (assertThat) самостоятельно.

Мой образец теста:

 public void shouldUnmarshalDataHeader() throws IOException {
        //given DataHeader unmarshalled from InputStream
        DataHeader actual = sut.parseDataHeader(stringToInputStream(BINARY_DATA_HEADER));

        //when we create DataHeader using java API
        DataHeader expected = DataHeaderBuilder
            .sampleInstance(sut.dateTimeProvider.getLocalDateTime());

        //then those two objects are equal
        Assertions.assertThat(actual).isEqualTo(expected);
    }

Подробная информация

Эта функция принадлежит библиотеке утверждений, а не библиотеке тестов. TestNG имеет встроенную библиотеку утверждений, но вы можете использовать любую другую библиотеку. Для меня https://joel-costigliola.github.io/assertj/ работает лучше всего. Сообщения с утверждениями лучше, чем сообщения от обычного testNG или JUnit. AssertJ предлагает свободный API. Существует очень мало кривой обучения.

Когда у тебя есть import static org.assertj.core.api.Assertions.*;Просто введите assertThat(something). и полный код из IDE поможет вам. Чем лучше вы используете утверждения, тем более читабельным будет ваш тест и тем лучше будут сообщения об ошибках.

растяжимый

Spring имеет встроенную поддержку TestNG. Ваш тест должен быть продлен AbstractTestNGSpringContextTests или же AbstractTransactionalTestNGSpringContextTests, После этого вы сможете загружать любой Spring Spring Context, bean-компонент Spring в свой тест, использовать транзакции.

См. http://docs.spring.io/spring/docs/current/spring-framework-reference/html/integration-testing.html для получения дополнительной информации.

Резюме

Для меня TestNG работает хорошо. Вы можете протестировать все, что можете протестировать с помощью Спока. Поскольку TestNG - это чистый Java, DSL для написания тестов не будет столь же многофункциональным, как Groovy в Spock. Но я считаю, что TestNG+AssertJ имеет более плавную кривую обучения, чем Спок (для Java-разработчика). Если кто-то заинтересован в использовании Groovy (может быть, вы тоже хотите использовать Groovy для производственного кода?), То Spock - прекрасный выбор, который стоит первоначальных вложений в обучение.

Для изучения TestNG я настоятельно рекомендую "Практическое модульное тестирование с TestNG и Mockito" ( http://practicalunittesting.com/) и "Тестирование Java следующего поколения: TestNG и расширенные концепции" ( http://testng.org/doc/book.html).

Обновление октябрь 2018

Выше пост был написан в 2016 году. На данный момент у нас Junit5. Junit5 закрывает пробел между junit4 и TestNG. Есть несколько мест, где Junit5 более многофункциональн, чем testNG (пример: лучшая поддержка параметризованных методов тестирования).

Я использовал jUnit5 в нескольких коммерческих проектах, и я доволен этим.

Junit5 по-прежнему является чистой Java, так что нет никакой поддержки на уровне языка для заданных когда тогда разделов или утверждений, как в споке. Я все еще использую AssertJ и несколько других сопутствующих инструментов (пример: https://github.com/awaitility/awaitility для тестирования асинхронных операций)

Источник
Другие вопросы по тегам