JUnit 4 проти TestNG - Оновлення 2013-2014 [закрито]

Раніше JUnit 4 і TestNG були порівнянними. Які плюси та мінуси двох тестових платформ?

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

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

Поки що це єдине, що я можу зазначити як перевагу TestNG перед JUnit4.

Intellij IDEA включає підтримку TestNG та JUnit нестандартно. Однак Eclipse підтримує лише JUnit з коробки та потребує встановленого плагіна TestNG, щоб він працював.

Однак більш прикрою проблемою, з якою я зіткнувся з TestNG, є те, що ваші тестові класи повинні розширюватися, PowerMockTestCaseякщо ви використовуєте PowerMock для знущання над залежностями у своїх тестах. Очевидно, існують способи налаштування фабрики об'єктів, про яку повинен знати ваш тестовий фреймворк при використанні PowerMock за допомогою спеціального методу або за допомогою testng.xmlвизначення набору, але на даний момент вони, здається, не працюють. Мені не подобається, коли тестові класи розширюють класи тестових фреймворків, це здається хаксом.

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

Виходячи з мого досвіду роботи з обома фреймворками, testng має кілька зручних функцій, які команда JUnit відмовляється впроваджувати протягом декількох років. З цієї причини я віддаю перевагу йому JUnit. Перетворити на testng просто, оскільки в основному він підтримує майже все в JUnit (навіть є плагін конвертера для затемнення), перетворення назад у JUnit не таке вже й велике через ці відсутні функції.

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

• Постачальники даних Testng трохи гнучкіші, ніж еквівалент JUnit. Ви можете вказати для кожного тесту, який метод постачальника даних повинен надавати вхідні дані, замість того, щоб мати підхід, який підходить для всіх, для всього класу, як у JUnit. Таким чином, ви можете мати позитивних і негативних постачальників даних про випадки для своїх тестів в одному класі. Дуже приємно мати.

• Ви можете позначити клас за допомогою @Testtestng, що означає: кожен загальнодоступний метод - це тест. У Junit вам потрібно скопіювати / вставити @Testкожен метод.

Роздратуванням обох є те, як Hamcrest поєднується з JUnit і як JUnit поєднується з testng. У Maven є інші банки, у яких немає цієї проблеми.

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

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

Якщо ви працюєте над проектом Java / Scala, і Gradle є вашим інструментом побудови на вибір, майте на увазі, що ScalaTestфреймворк JUnitRunnerповинен запускати ваші тести Scala. Іншими словами, у вас є вибір:

• Тести Java JUnit + тести Scala виконуються з JUnitRunner => Краща інтеграція Gradle
• Тести JavaNG-тести + Тести Scala працюють із Scala Runner => Погана інтеграція Gradle, оскільки тест-версія Scala є єдиним масовим завданням з точки зору Gradle.

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

Коротко..

Якщо ваш обсяг обмежений тонкими детальними модульними тестами без залежностей між ними, тоді можна використовувати JUnit.

Якщо ваша область вимагає функціонального тестування, яке може / може не вимагати залежностей та спільного використання даних (параметрів) між тестами, виберіть TestNG. Крім того, TestNG може виконувати модульне тестування, подібне до JUnit. ТАК ви можете мати набір модульних тестів та набір функціональних тестів.