JUnit против TestNG

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Я также использовал обе рамки. Но я с помощью Hamcrest для assertations. 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.

In simple terms, TestNG = JUnit + lot more...So, Why debate ? go and grab TestNG :-)

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

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

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

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

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

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

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

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

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

   б) @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 = { "dependOnSomething"})

Эта функция не существует в JUnit

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

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

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

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

1. Быстрый JUnit против TestNG Сравнение
2. JUnit vs. TestNG: Какие Testing Framework Вы должны выбрать?

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

Мое мнение о том, что делает 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 играет кетчуп с TestNG с точки зрения функциональности, они преодолели разрыв примерно то, что с v4, но не достаточно хорошо, на мой взгляд. Такие вещи, как аннотация и dataproviders все еще намного лучше в TestNG. Кроме того, они являются более гибкими в плане выполнения теста, так как TestNG имеет тестовую зависимость, группировка и упорядочение.

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

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

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

Чуть не забыл, а также использовать Test Data Builder шаблон , это в сочетании с DataProvider аннотацию TestNG является очень полезным.

Мне нравится аккуратная и легкая интеграция TestNG с Guice.