JUnit против TestNG [закрыто]

В настоящее время мы все еще используем JUnit 3 для запуска наших тестов. Мы думали о переходе на JUnit 4 для написания новых тестов, но я уже некоторое время слежу за TestNG. Какой у вас был опыт работы с JUnit 4 или TestNG, и что, кажется, лучше работает для очень большого количества тестов? Для нас также важна гибкость в написании тестов, так как наши функциональные тесты охватывают широкий спектр и должны быть написаны разными способами для получения результатов.

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

Я использовал и то, и другое, но должен согласиться с Джастином Стандардом, что вам не следует думать о переписывании существующих тестов в какой-либо новый формат. Независимо от решения, запустить оба варианта довольно просто. TestNG стремится быть более настраиваемым, чем JUnit, но в итоге они оба работают одинаково хорошо.

TestNG имеет удобную функцию, с помощью которой вы можете пометить тесты как определенную группу, а затем легко запустить все тесты определенной группы или исключить тесты определенной группы. Таким образом, вы можете отметить тесты, которые выполняются медленно, как в группе «медленные», а затем игнорировать их, если вам нужны быстрые результаты. В их документации предлагается пометить некоторые подмножества как тесты «проверки», которые следует запускать всякий раз, когда вы регистрируете новые файлы. Я никогда не видел такой функции в JUnit, но опять же, если у вас ее нет, вы не t ДЕЙСТВИТЕЛЬНО скучаю по нему.

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

Самое большое преимущество TestNG - это аннотации ... которые JUnit все равно добавил в версию 4.

Во-первых, я бы сказал, не переписывайте все свои тесты только в соответствии с последней модой. Junit3 работает отлично, и введение аннотаций в 4 не очень вам выгодно (на мой взгляд). Гораздо важнее, чтобы вы, ребята, писали тесты, и похоже, что вы это делаете.

Используйте то, что кажется наиболее естественным и помогает выполнять работу.

Не могу комментировать TestNG b / c, я его не использовал. Но я бы порекомендовал unitils , отличную оболочку для JUnit / TestNG / DBUnit / EasyMock, независимо от того, какой маршрут вы выберете. (Он поддерживает все упомянутые выше ароматы)

Самая большая привлекательность TestNG для меня - это группы тестирования поддержки и, что более важно, зависимости тестовых групп (пометка теста как зависимого от группы приводит к тому, что тесты просто пропускают выполнение, когда зависимая группа терпит неудачу).

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

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

(отказ от ответственности - я вообще не использовал JUnit 4.x, поэтому я не могу реально комментировать там достижения или новые функции).

Примерно год назад у нас была такая же проблема. Некоторое время я размышлял, какой ход лучше, и в конце концов мы поняли, что TestNG не имеет «убийственных функций». Это приятно, и в нем есть некоторые функции, которых нет в JUnit 4, но они нам не нужны.
Мы не хотели, чтобы люди чувствовали себя неудобно при написании тестов, знакомясь с TestNG, потому что мы хотели, чтобы они продолжали писать много тестов.
Кроме того, JUnit в значительной степени является стандартом де-факто в мире Java. Нет достойного инструмента, который бы не поддерживал его из коробки, вы можете найти много помощи в Интернете, и за последний год они добавили много новых функций, что показывает, что он жив.

Мы решили придерживаться JUnit и никогда не оглядывались назад.

Приветствую всех вышеперечисленных. Я лично обнаружил, что в TestNG мне больше нравится:

1. Для @BeforeClassTestNG происходит после создания класса, поэтому вы не ограничены только возможностью вызывать в нем статические методы вашего класса.

2. Параллельные и параметризованные тесты, возможно, мне просто не хватает жизни ... но я просто получаю удовольствие от написания одного набора тестов Selenium, принимая имя драйвера в качестве параметра. Затем определите 3 параллельные тестовые группы, по одной для драйверов IE, FF и Chrome, и наблюдайте за гонкой! Изначально я сделал 4, но слишком много страниц, над которыми я работал, по той HtmlUnitили иной причине ломают драйвер.

Да, наверное, нужно найти ту жизнь. ;)

Я хотел поделиться тем, с чем столкнулся сегодня. Я обнаружил, что встроенный параметризованный бегун в Junit4 довольно грубый по сравнению с TestNG (я знаю, что у каждого фреймворка есть свои сильные стороны, но все же). Аннотация Junit4 @parameters ограничена одним набором параметров. Я столкнулся с этой проблемой при проверке допустимого и недопустимого поведения для функциональности в том же тестовом классе. Таким образом, будет использован первый общедоступный статический аннотированный метод, который он найдет, но он может найти их в любом порядке. Это заставляет нас писать разные классы без необходимости. Однако TestNG предоставляет чистый способ предоставления различных поставщиков данных для каждого метода. Таким образом, мы можем протестировать один и тот же блок кода действительным и недопустимым способом в одном и том же тестовом классе, поместив действительные / недопустимые данные отдельно. Я пойду с TestNG.

Еще одно преимущество TestNG - поддержка параллельного тестирования. Думаю, в нашу эпоху многоядерных процессоров это важно.

Я тоже использовал оба фреймворка. Но я использую hamcrest для утверждений. Hamcrest позволяет легко написать собственный метод assert. Так что вместо

assertEquals(operation.getStatus(), Operation.Status.Active);

Ты можешь написать

assertThat(operation, isActive());

Это дает вам возможность использовать более высокий уровень абстракции в ваших тестах. И это делает ваши тесты более надежными.

JUnit 4 Vs TestNG - Сравнение с mkyong.com (обновлено 2013 г.).

Заключение: я предлагаю использовать TestNG в качестве основной среды модульного тестирования для проекта Java, потому что TestNG более продвинут в параметризации тестирования, тестирования зависимостей и тестирования набора (концепция группировки).

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

Кроме того, TestNG также охватывает всю базовую функциональность JUnit4 . Для меня просто нет причин использовать JUnit.

Проще говоря, TestNG = JUnit + многое другое. Итак, зачем спорить? иди и возьми TestNG :-)

Вы можете найти более подробное сравнение здесь .

Несколько дополнений к ответу Майка Стоуна:

1) Чаще всего я использую группы TestNG, когда хочу запустить один тестовый метод в тестовом наборе. Я просто добавляю этот тест в группу «Фил», а затем запускаю эту группу. Когда я использовал JUnit 3, я закомментировал записи для всех методов, кроме того, который я хотел запустить в методе «набора», но обычно забывал их раскомментировать перед возвратом. С группами у меня больше нет этой проблемы.

2) В зависимости от сложности тестов перенос тестов с JUnit3 на TestNG может быть выполнен в некоторой степени автоматически с помощью sed и создания базового класса для замены TestCase, который static импортирует все методы утверждения TestNG.

У меня есть информация о переходе с JUnit на TestNG здесь и здесь .

Почему мы используем TestNG вместо JUnit?

1. Декларация @BeforeClassи @AfterClassметод должен быть статическим , в то время как JUnit, есть больше гибкости в TestNG в объявлении метода, он не имеет этих ограничений.

2. В TestNG мы можем параметризовать тесты двумя способами . @Parameter или @DataProvider аннотация.

   i) @Parameter для простых случаев, когда требуется сопоставление значений ключа. (данные предоставляются через файл xml)

   ii) @DataProvider для сложных случаев. Используя 2-мерный массив, он может предоставлять данные.

3. В TestNG, поскольку метод @DataProvider не обязательно должен быть статическим, мы можем использовать несколько методов поставщика данных в одном тестовом классе.

4. Тестирование зависимостей: в TestNG, если начальный тест завершился неудачно, все последующие зависимые тесты будут пропущены и не помечены как неудачные. Но JUnit отметил, что это не удалось.

5. Группировка: отдельные тесты могут принадлежать к нескольким группам, а затем выполняться в разных контекстах (например, медленные или быстрые тесты). Аналогичная функция существует в категориях JUnit, но в ней отсутствуют аннотации @BeforeGroups / @AfterGroups TestNG, которые позволяют инициализировать тест / разорвать его.

6. Параллелизм: если вы хотите запустить один и тот же тест параллельно в нескольких потоках, TestNG предлагает вам простую в использовании аннотацию, в то время как JUnit не предлагает простой способ сделать это из коробки.

7. TestNG @DataProvider также может поддерживать XML для подачи данных, CSV или даже простых текстовых файлов.

8. TestNG позволяет объявлять зависимости между тестами и пропускать их, если тест зависимости не прошел.

@Test (dependsOnMethods = {"dependsOnSomething"})

Этой функции нет в JUnit

9. Составление отчетов:

Отчеты TestNG по умолчанию создаются в папке вывода теста, которая включает отчеты HTML со всеми данными теста, пройденными / неудачными / пропущенными, длительностью их выполнения, используемыми входными данными и полными журналами тестирования. Кроме того, он также экспортирует все в файл XML, который можно использовать для создания собственного шаблона отчета.

На фронте JUnit все эти данные также доступны через XML, но готового отчета нет, и вам нужно полагаться на плагины.

Ссылка на ресурс:

1. Быстрое сравнение JUnit и TestNG
2. JUnit против TestNG: какую среду тестирования выбрать?

В этом учебном пособии показано хорошее различие: TestNG против JUnit: в чем разница?

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

Хорошо, во-первых, JUnit играет в догонялки с TestNG с точки зрения функциональности, они кое-что преодолели с помощью v4, но, на мой взгляд, недостаточно хорошо. Такие вещи, как аннотации и поставщики данных, по-прежнему намного лучше в TestNG. Кроме того, они более гибкие с точки зрения выполнения тестов, поскольку TestNG имеет тестовую зависимость, группировку и порядок.

JUnit по-прежнему требует, чтобы определенные методы до и после были статическими, что ограничивает то, что вы можете делать до запуска тестов, TestNG никогда не имеет этой проблемы.

TBH, в основном различия между двумя фреймворками не имеют большого значения, если вы не сосредоточены на тестировании интеграции / автоматизации. По моему опыту, JUnit создан с нуля для модульного тестирования и теперь продвигается к более высоким уровням тестирования, что, по мнению ИМО, делает его неподходящим инструментом для работы. TestNG хорошо справляется с модульным тестированием, а благодаря надежному предоставлению данных и отличным возможностям выполнения тестов работает еще лучше на уровне тестирования интеграции / автоматизации.

Теперь о том, что я считаю отдельной проблемой, как писать хорошо структурированные, читаемые и поддерживаемые тесты. Я уверен, что вы знаете большую часть этого, но такие вещи, как Factory Pattern , Command Pattern и PageObjects (если ваши тестовые веб-сайты) жизненно важны, очень важно иметь уровень абстракции между тем, что ваше тестирование (SUT), и тем, что фактический тест есть (утверждения бизнес-логики). Чтобы получить более удобные утверждения, вы можете использовать Hamcrest . Используйте наследование / интерфейсы javas, чтобы уменьшить повторение и обеспечить общность.

Чуть не забыл, также используйте шаблон построителя тестовых данных , это в сочетании с аннотацией поставщика данных TestNG очень полезно.

Мое мнение о том, что делает TestNG действительно более мощным:

1.  JUnit still requires the before/after class methods to be static, which limits
    what you can do prior to the running of tests, TestNG never has this issue.

2.  TestNG @Configuration methods can all take an optional argument to their 
    annotated methods in the form of a ITestResult, XmlTest, Method, or 
    ITestContext.  This allows you to pass things around that JUnit wouldn't 
    provide you.  JUnit only does this in listeners and it is limited in use.

3.  TestNG comes with some pre-made report generation classes that you can copy
     and edit and make into your own beautiful test output with very little 
     effort. Just copy the report class into your project and add a listener 
     to run it.  Also, ReportNG is available.

4.  TestNG has a handful of nice listeners that you can hook onto so you can do
     additional AOP style magic at certain phases during testing.