JUnit 4 против TestNG - Обновление 2013 - 2014

Ответ 1

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

Насколько я могу судить по JUnit4, вам нужно создать отдельный тестовый класс для каждого набора параметров, с которыми вы хотите протестировать (с помощью @RunWith(Parameterized.class)). С помощью TestNG у вас может быть несколько поставщиков данных в одном тестовом классе, поэтому вы можете хранить все свои тесты для одного класса в одном классе тестов.

Пока это единственное, что я могу указать как преимущество TestNG над JUnit4.

Intellij IDEA включает поддержку TestNG и JUnit из коробки. Однако Eclipse поддерживает только JUnit и нуждается в плагине TestNG, чтобы он работал.

Однако более раздражающая проблема, с которой я столкнулся с TestNG, заключается в том, что ваши тестовые классы должны расширять PowerMockTestCase, если вы используете PowerMock для издевательства зависимостей в своих тестах. По-видимому, есть способы настроить объект-w770, о котором должна знать ваша тестовая структура при использовании PowerMock с помощью специального метода или с помощью определения пакета testng.xml, но в настоящий момент они, похоже, разбиты. Мне не нравится, когда тестовые классы расширяют классы тестовых рамок, это кажется хакерским.

Если вы не используете PowerMock, это, конечно, не проблема, но в целом мне кажется, что JUnit4 лучше поддерживается.

Ответ 2

Основываясь на моем опыте работы с обеими рамками, testng имеет несколько удобных функций, которые команда JUnit отказалась реализовать в течение нескольких лет. По этой причине я предпочитаю JUnit. Преобразование в testng легко, поскольку в основном поддерживает почти все в JUnit (там есть плагин конвертера для eclipse), преобразование обратно в JUnit не так велико из-за этих недостающих функций.

• В методах testng @BeforeClass не статичны и выполняются до запуска тестов в этом классе, а не при загрузке тестового класса (поведение JUnit). У меня когда-то был проект JUnit, где все тесты базы данных (несколько десятков) инициализировали базу данных прямо в начале, что было довольно идиотским поведением. В сообществе JUnit было много споров и против этого. Суть его заключалась в том, что каждый тестовый метод должен иметь свое собственное тестовое приспособление, и поэтому у вас не должно быть метода стиля beforeAll, который не статичен, потому что это позволит вам тайно установить переменную экземпляра один раз, а затем использовать ее во всех ваших тестах. Действительно, но очень раздражает интеграционные тесты. TestNG дает пользователям выбор здесь. Junit не по дизайну, что раздражает.

• Поставщики данных Testng немного более гибкие, чем эквивалент JUnit. Вы можете указать для каждого теста, какой метод поставщика данных должен предоставлять вход, вместо того, чтобы иметь один размер для всего подхода для всего класса, как в JUnit. Таким образом, вы можете иметь поставщиков положительных и отрицательных случаев для своих тестов в одном классе. Очень приятно иметь.

• Вы можете пометить класс @Test в testng, что означает: каждый публичный метод является тестом. В Junit вам нужно скопировать/вставить @Test для каждого метода.

Досада с обеих заключается в том, как hamcrest в комплекте с JUnit и способом, которым JUnit связан с testng. В maven есть измененные банки, у которых нет этой проблемы.

Мое большое беспокойство в обеих структурах заключается в том, что они оба, похоже, перестали развиваться. Релизы становятся все менее частыми и, как правило, имеют все меньше и меньше примечательных особенностей. Например, все движение BDD мало повлияло на обе структуры. Кроме того, JUnit мог бы просто принять большинство из того, что я перечислил выше. Нет хорошей технической причины, по которой JUnit не может реализовать ни одну из этих вещей; люди, стоящие за JUnit, просто предпочитают не выполнять эти вещи. Кажется, что оба проекта не видят перспектив для будущих направлений, и они, кажется, счастливы, делая небольшие изменения в течение последних нескольких лет.

Ответ 3

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

Ответ 4

Если вы работаете над проектом Java/ Scala, а Gradle - ваш инструмент построения, вы должны иметь в виду, что ScalaTest framework имеет только JUnitRunner для запуска ваших тестов scala. Другими словами, у вас есть выбор:

• Тесты Java JUnit + scala Тесты выполняются с интеграцией JUnitRunner = > Better Gradle
• Тесты тестового тестирования Java + scala Тесты выполняются с scala Runner = > Poor Gradle Интеграция, так как scala test runner - это отдельная задача с точки зрения Gradle.

Ответ 5

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

Ответ 6

В двух словах.

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

Если ваша область требует функционального тестирования, которое может/не может требовать зависимости и совместного использования данных (параметров) между тестами, то выберите TestNG. Кроме того, TestNG может выполнять модульное тестирование, подобное JUnit. Итак, вы можете иметь набор модульных тестов и набор функциональных тестов.