Я знаком с jUnit и слышал, что TestNG может быть решением некоторых из раздражителей jUnit - например. его настойчивость в создании отдельного экземпляра тестового класса для каждого теста, что вынуждает меня использовать статическое поле для объектов, которые я хочу повторно использовать между тестами.
(Скажем, вы согласны со мной в том, что это недостаток, и не ставьте этот вопрос на что-то не так)
Что я спрашиваю здесь, какие недостатки имеет TestNG, по сравнению с jUnit? Почему бы не использовать TestNG, считая, что это новый проект, и нет каких-либо затрат на миграцию?
Я создатель TestNG. Я не буду взвешивать, так как я, очевидно, предвзятый, но я рад ответить на любой вопрос, который у вас может возникнуть в отношении TestNG.
Энди: Спасибо за ваш комментарий. FYI (вы, наверное, уже знаете это, но, возможно, оригинальный плакат не работает), есть подключаемый модуль TestNG Eclipse (который я разрабатываю параллельно к TestNG).
Я лично не сталкивался с существенными недостатками по сравнению с JUnit.
В начале нового проекта моя команда переключилась на TestNG и не пожалела. TestNG более мощный и поддерживает более широкое использование, чем модульные тесты.
Некоторые инструменты поддерживают JUnit, но не TestNG. Это инструменты, которые мне еще не нужны. Например:
Являясь огромным сторонником TestNG, я все еще вижу, что он рассматривается как номер 2 авторами. Многие инструменты и библиотеки поддерживают JUnit с самого начала, но вам нужно подождать, пока они также не будут поддерживать поддержку TestNG. Это может быть серьезным недостатком, если вы планируете использовать последнюю технологию жужжания.
В течение многих лет ситуация улучшилась. Например, это было проблемой с Spring, Gradle или Maven Surefire, но это уже не проблема, потому что все они поддерживают TestNG сейчас. Также все IDE обрабатывают обе структуры одинаково.
Итак, убедитесь, что другие технологии, которые вы планируете использовать, отлично сочетаются с TestNG. Это редко бывает проблемой, но еще лучше убедитесь в этом.
Для меня самой большой проблемой является интеграция с spring. Я не люблю расширять классы TestNg и писать код следующим образом:
@Test
@ContextConfiguration(locations = { "classpath:spring-test-config.xml" })
public class TestSpring extends AbstractTestNGSpringContextTests {
Потому что обычно у меня есть своя иерархия тестовых классов. Это была основная причина, по которой я прекратил использовать TestNg.
Я должен согласиться с тем, что параметризованный тест был очень привлекательным для меня. Но их можно легко заменить поставщиком данных junit.
https://github.com/TNG/junit-dataprovider/wiki/Getting-started