Недостатки TestNG по сравнению с jUnit?

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

(Допустим, вы согласны со мной, что это недостаток, и не превращать этот вопрос в то, чем он не является)

Я спрашиваю здесь, какие недостатки есть у TestNG по сравнению с jUnit? Почему бы не использовать TestNG, если это новый проект и нет никаких затрат на миграцию?


junit testng
person ripper234    schedule 23.11.2010    source источник
comment
Вы знаете, что повторное использование объектов между тестами увеличивает связь между тестами? Связанные тесты — это полное проклятие хорошего модульного тестирования, поскольку они позволяют проблемам с одним тестом привести к сбоям (или исключениям) в другом…   -  person Donal Fellows    schedule 24.11.2010
comment
@Donal, давай не будем задавать этот вопрос об этом. При написании тяжелых интеграционных тестов с большим количеством компонентов отказ от повторного использования является еще одним бедствием, потому что выполнение тестов может занять несколько часов.   -  person ripper234    schedule 24.11.2010
comment
Согласованный; это побочный вопрос.   -  person Donal Fellows    schedule 24.11.2010
comment
Повторное использование объектов между тестами не обязательно увеличивает связь между тестами, особенно если эти объекты неизменяемы. Преимущество этого заключается в том, что вам не нужно создавать дорогие объекты снова и снова. TestNG дает вам выбор любого из подходов, в то время как JUnit заставляет вас выбрать один из них.   -  person Cedric Beust    schedule 28.11.2010

Ответы (4)


arrow_upward
7
arrow_downward

Я создатель TestNG. Я не собираюсь вмешиваться, так как я явно предвзят, но я буду рад ответить на любой ваш вопрос о TestNG.

Энди: спасибо за ваш комментарий. К вашему сведению (вы, вероятно, уже знаете это, но, возможно, исходный постер не знает), есть подключаемый модуль TestNG Eclipse. (который я разрабатываю параллельно с TestNG).

person Cedric Beust    schedule 23.11.2010
comment
Привет :) Приятно познакомиться, мне нравится, что ты можешь знакомиться с людьми на SO. Я использую TestNG всего около 10 минут ... Почему вы решили не использовать атрибут @Ignore? Что мне нравится в @Ignore, так это то, что вы можете указать причину игнорирования внутри аннотации, и, насколько я знаю, вы не можете сделать это с enabled=false - person ripper234; 24.11.2010
comment
В TestNG вы помечаете тест как проигнорированный с помощью @Test(enabled = false). Это упрощает обнаружение для новичков (просто введите @Test(затем Control-Space, и вы получите список всех доступных атрибутов). - person Cedric Beust; 28.11.2010

arrow_upward
5
arrow_downward

Существенных недостатков по сравнению с JUnit лично я не встретил.

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

Некоторые инструменты поддерживают JUnit, но не поддерживают TestNG. Это инструменты, которые мне пока не нужны. Например:

  • Google CodePro Analytix поддерживает генерацию модульных тестов JUnit.
  • Eclipse IDE для разработки RCP поддерживает конфигурации запуска/отладки для «тестов подключаемых модулей JUnit».
person Andy Thomas    schedule 23.11.2010

arrow_upward
3
arrow_downward

Будучи огромным сторонником TestNG, я все еще вижу, что авторы инструментов считают его номером 2. Многие инструменты и библиотеки поддерживают JUnit с самого начала, но вам придется подождать, пока они также не реализуют поддержку TestNG. Это может быть серьезным недостатком, если вы планируете использовать новейшие технологии гудения.

С годами ситуация намного улучшилась. Например, раньше это было проблемой для Spring, Gradle или Maven Surefire, но теперь это не проблема, поскольку все они теперь поддерживают TestNG. Также все IDE одинаково относятся к обоим фреймворкам.

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

person Tomek Kaczanowski    schedule 05.01.2012

arrow_upward
1
arrow_downward

Для меня самой большой проблемой является интеграция с Spring. Мне не нравится расширять классы TestNg и писать такой код:

@Test
@ContextConfiguration(locations = { "classpath:spring-test-config.xml" })
public class TestSpring extends AbstractTestNGSpringContextTests {

Потому что обычно у меня есть своя иерархия тестовых классов. Это была основная причина, по которой я перестал использовать TestNg.

Я должен согласиться, что параметризованный тест был очень привлекательным для меня. Но их можно легко заменить на junit data-provider.

https://github.com/TNG/junit-dataprovider/wiki/Getting-started

person Yurii Bondarenko    schedule 06.10.2015