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

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

Старі тести не будуть переписуватися, оскільки вони добре виконують свою роботу. Що я хотів би побачити в нових тестах, це гнучкість у способі написання тесту, природні твердження, групування та легко розповсюджені виконання тестів.

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

TestNG має чітку функцію, де ви можете позначити тести як певну групу, а потім легко запустити всі тести певної групи або виключити тести певної групи. Таким чином, ви можете позначати тести, які працюють повільно, як у "повільній" групі, а потім ігнорувати їх, коли ви хочете швидких результатів. Пропозиція з їхньої документації полягає в тому, щоб позначити деякий підмножина як тести "checkin", які слід запускати щоразу, коли ви перевіряєте нові файли. Я ніколи не бачив такої функції в 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. Тест @BeforeClassдля TestNG відбувається після створення класу, тому вас не обмежує лише виклик статичних методів свого класу в ньому.

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

Так, напевно, потрібно знайти таке життя. ;)

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

Ще однією перевагою TestNG є підтримка паралельного тестування. У нашу епоху багатоядерних це важливо, я думаю.

Я також використав обидві рамки. Але я використовую hamcrest для тверджень. Hamcrest дозволяє легко написати власний метод затвердження. Тож замість

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 + багато іншого. Отже, навіщо дискутувати? іди і схопи ТестНГ :-)

Більш детальне порівняння можна знайти тут .

Кілька доповнень до відповіді Майка Стоун:

1) Найчастіше я використовую групи TestNG, коли я хочу запустити один тестовий метод у тестовому наборі. Я просто додаю цей тест до групи "phil", а потім запускаю цю групу. Коли я використовував JUnit 3, я б прокоментував записи для всіх методів, окрім того, який я хотів запустити методом "набір", але тоді зазвичай забув би прокоментувати їх перед реєстрацією. З групами у мене вже немає цієї проблеми.

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

У мене є інформація про міграцію з JUnit до TestNG тут і тут .

Чому ми використовуємо TestNG замість JUnit?

1. Оголошення @BeforeClassта @AfterClassметод повинні бути статичними в JUnit, тоді як у декларації методу більше гнучкості в TestNG, ці обмеження не мають.

2. У TestNG ми можемо параметризувати тести двома способами . Анотація @Parameter або @DataProvider.

   i) @ Параметр для простих випадків, коли потрібне відображення ключових значень. (дані надаються через XML-файл)

   ii) @DataProvider для складних випадків. Використовуючи двовимірний масив, він може надавати дані.

3. У TestNG, оскільки метод @DataProvider не повинен стати статичним, ми можемо використовувати декілька методів постачальника даних в одному тестовому класі.

4. Тестування залежності: У TestNG, якщо початковий тест не вдається, то всі наступні залежні тести будуть пропущені, а не позначені як невдалі. Але JUnit відзначив, що це не вдалося.

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

6. Паралелізм: Якщо ви хочете паралельно виконувати один і той же тест паралельно на декількох потоках, TestNG вас охопив простим у використанні анотацією, тоді як JUnit не пропонує простий спосіб зробити це поза коробкою.

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

8. TestNG дозволяє оголосити залежності між тестами та пропустити їх, якщо тест на залежність не пройшов.

@Test (залежно від методу = {"залежно від одного"})

Ця функція не існує в JUnit

9. Звітність:

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

На передній панелі JUnit всі ці дані також доступні через XML, однак у звіті про вікно немає жодної інформації, і вам потрібно покладатися на плагіни.

Посилання на ресурс:

1. Швидке порівняння JUnit з TestNG
2. JUnit vs. TestNG: Яку рамку тестування слід вибрати?

Хороша відмінність дається в цьому підручнику пліч-о-пліч: TestNG VS JUnit: У чому різниця?

Ваше питання здається мені складеним. З одного боку ви хотіли б порівняти дві тестові рамки, з іншого боку, ви хочете легко впроваджувати тести, мати природні твердження тощо.

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

JUnit все ще вимагає, щоб певні методи до / після були статичними, що обмежує те, що ви можете зробити до запуску тестів, TestNG ніколи не має цього питання.

TBH, в основному відмінності між двома рамками не означають багато, якщо не зосередитись на тестуванні інтеграції / автоматизації. З мого досвіду JUnit побудований з нуля для тестування одиниць, і тепер його підштовхують до вищих рівнів тестування, що IMO робить його неправильним інструментом для роботи. TestNG добре працює на тестуванні одиниць, а завдяки надійному забезпеченню даних та великим можливостям виконання тесту, працює ще краще на рівні тесту на інтеграцію / автоматизацію.

Тепер для того, що я вважаю, є окремим питанням, як написати добре структуровані, читабельні та реконструйовані тести. Більшу частину цього я впевнений, що ви знаєте, але такі речі, як Factory Pattern , Command Pattern та PageObjects (якщо ваші веб-сайти для тестування) є життєво важливими, дуже важливо мати шар абстракції між тим, що проводить тестування (SUT) та фактичним тестом. є (твердження про логіку бізнесу). Для того, щоб мати набагато приємніші твердження, ви можете використовувати Hamcrest . Використовуйте спадщину / інтерфейси javas, щоб зменшити повторення та забезпечити спільність.

Майже забули, також використовуйте шаблон тестування даних Data Builder , це в поєднанні з анотацією Dataprovider DataNG дуже корисно.

Моя думка про те, що робить 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.