JUnit vs TestNG [закрыто]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

У меня есть информация о моей миграции из JUnit в TestNG здесь и здесь .

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

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

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

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

assertThat(operation, isActive());

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

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

Приветствия всему вышесказанному. Некоторые другие вещи, которые я лично нашел, мне нравятся больше в TestNG:

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

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

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

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

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

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

TBH, в основном различия между двумя средами не имеют большого значения, если вы не сосредоточены на тестировании интеграции / автоматизации. JUnit, исходя из моего опыта, создан с нуля для модульного тестирования и в настоящее время движется к более высоким уровням тестирования, что делает IMO неподходящим инструментом для работы. 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.

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

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

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

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

Проще говоря, 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 первоначальный тест не пройден, все последующие зависимые тесты будут пропущены, а не помечены как неудачные. Но Юнит отметил, что это не удалось.

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

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

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

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

@Test (absoluteOnMethods = {"depenOnSomething"})

Эта функциональность не существует в JUnit

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

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

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

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

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

Хорошая разница дается в этом уроке бок о бок: TestNG против JUnit: в чем разница?