Существует несколько видов тестов, и JUnit и TestNG поддерживают их все.
В случае юнит-тестов вы можете запустить их все и получить обратную связь в течение нескольких секунд или минут.
Когда дело доходит до интеграционных или сквозных тестов, вы можете сгруппировать свои тесты из-за временного фактора.
Допустим, у вас есть юнит-тесты, API-тесты и даже тесты GUI.
Хотя модульные тесты могут выполняться с каждой сборкой, другие тесты могут занять слишком много времени.
Пример:
В одном проекте у меня было более 300 тестов GUI, и для их параллельного запуска потребовалось 2 часа. Когда мы ввели исправление для определенного компонента, и нам нужно было развернуть его как можно быстрее, мы запускали регрессионные тесты только для компонента. Именно тогда группировка может прийти в себя.
Другой пример:
В моем текущем проекте у меня есть управляемые данными тесты API. Чтобы протестировать компонент, мне нужно выполнить 5000 запросов с помощью автоматического теста, и это займет до 30 минут. Это только для одного компонента, где у нас сейчас около 14. Представьте себе, запустив полный набор тестов.
Решение для запуска всех видов тестов для полной регрессии с каждой сборкой будет непростым для непрерывной интеграции / непрерывного развития.
Другой подход - запускать только тесты на дым, но вам все равно нужно либо сгруппировать свои тесты, либо создать определенный класс Runner (точно так же, как JUnit runner или Cucumber runner), чтобы выполнить только часть тестов.
Вся цель автоматизированных тестов - обеспечить быструю обратную связь, если разработанная версия не содержит ошибок из-за ухудшения качества. Если мы должны ждать несколько часов для обратной связи. Если у нас его не будет, нам придется отложить каждую версию / сборку (зависит от того, когда мы запустим эти тесты), что может даже вступить в конфликт с SLA, который мы согласовали с заказчиком.
Чтобы быть еще более конкретным:
Предположим, у нас есть критическая ошибка в платежных системах, и в соответствии с SLA мы должны исправить такие критические ошибки в течение 8 часов. Разработчик исправляет ошибку, создает сборку приложения для развертывания в среде тестирования, и мы хотим убедиться, что мы не добавили никаких новых ошибок. Полная регрессия автоматических тестов, включая юнит-тесты, API-тесты и тесты GUI, может занять до нескольких часов, но у нас есть только несколько часов, чтобы представить изменения нашим клиентам (производственная среда). Вместо того, чтобы запускать весь набор тестов, мы можем запустить группу тестов, касающихся платежей.
Надеюсь, это поможет