Comments 15
А почему первым выбирается TestNG? Почему нельзя сделать аналогичный механизм как в slf4j? Или я что-то не так понял?
А вообще идея в чем-то имеет право на жизнь. Но было бы здорово, если бы фреймворк объединял возможности, а не использовал пересечение. Это было бы реально круто.
А вообще идея в чем-то имеет право на жизнь. Но было бы здорово, если бы фреймворк объединял возможности, а не использовал пересечение. Это было бы реально круто.
Да, звучит логично.
Как вариант — фреймворк будет предоставлять полный функицонал обоих. А в случае, если отсутсвует нужная либа, то логировать варнинг о нехватке зависимостей и использовать какие-то стабы для отсутсвующей функциональности. Я правильно понял мысль?
Как вариант — фреймворк будет предоставлять полный функицонал обоих. А в случае, если отсутсвует нужная либа, то логировать варнинг о нехватке зависимостей и использовать какие-то стабы для отсутсвующей функциональности. Я правильно понял мысль?
Да.
использовать какие-то стабы для отсутсвующей функциональности
Зачем, когда есть maven?
Ну изначальный смысл либы был именно в ситуации, когда нужно переключиться на другой фреймворк, при этом убрав старый. Чтобы в проекте не получилось 100500 тестовых фреймворков. Если нет проблемы в том, чтобы докинуть пару-тройку тестовых фреймворков, то эта либа не нужна. Ну разве что в ситуации, когда разработчику хочется писать все тесты в одном стиле.
если testng принимает на вход хамстерские матчеры (из библиотеки hamster), то интерфейс функций упрощается.
а если использовать import static, то и usingTestNG/usingJUnit указывать не нужно
а если использовать import static, то и usingTestNG/usingJUnit указывать не нужно
Честно говоря я не видел в API testng методы с матчерами. В этом конечно есть небольшая проблема. Многие используют этот функционал junit`а. Но чтобы сделать его в либе, придется выцепить этот код из junit`а.
Возможно, Вы имели ввиду не hamster, а hamcrest? Если да, то полностью поддерживаю. Очень ценю hamcrest как гибкое средство построения сложных ассертов, и не в последнюю очередь как источник внятных сообщений об ошибках.
В контексте статьи хочу также добавить, что hamcrest вкупе с мавеном позволяли мне до сих пор менять junit на tesng и наоборот без особых проблем.
В контексте статьи хочу также добавить, что hamcrest вкупе с мавеном позволяли мне до сих пор менять junit на tesng и наоборот без особых проблем.
«TestNG. Люблю группы», — никогда бы не пришли на ум группы, если меня спросят о плюсах TestNG, скорее, поставщики данных и своя реализация различных TestNGListener'ов — такого, вроде, в JUnit так и не появилось?
Даже не знаю, у меня почему-то именно группы сразу пришли на ум, как киллерфича :).
По поводу листенеров, есть вот такое org.junit.runner.notification.RunListener и org.junit.runner.notification.RunNotifier. Я честно говоря с ними не работал, но возможно функционал достаточно похож.
Наверное для них тоже есть смысл добавить поддержку в либу.
По поводу листенеров, есть вот такое org.junit.runner.notification.RunListener и org.junit.runner.notification.RunNotifier. Я честно говоря с ними не работал, но возможно функционал достаточно похож.
Наверное для них тоже есть смысл добавить поддержку в либу.
В ответ но опрос: пользуюсь JUnit и Spock. Spock идеален для проверки «чистых» функций, которые к тому же часто являются приватными методами. А чистый JUnit для больших тестов, в которых Mock-объектов создано множество. И оба прекрасно уживаются вместе (Spock использует JUnit runner). Могу привести пример, если кому интересно.
Sign up to leave a comment.
Общий API для JUnit и TestNG