Я не использую testNG, но я думаю, что эта функция может быть полезна иногда.
Я согласен с идеей независимых тестов, а это означает, что данные, созданные для одного теста, не должны использоваться другим тестом, чтобы избежать побочных эффектов.
Однако иногда вы знаете, что если ваша программа не может выполнить простую задачу A, она не сможет выполнить более сложную задачу B. Поэтому, если тест для A терпит неудачу, вы знаете, что тест для B также потерпит неудачу. Например, я не думаю, что могу разобрать сложную строку json (task/test B), если моя программа даже не может разобрать '{"a":1}'
(задача/тест A).
Если у вас есть регрессия, которая делает задачу невозможной, все более сложные операции, такие как B, потерпят неудачу, и причина не будет очевидна с первого взгляда (отчет покажет X неудачные тесты, тогда как фиксация только одна решит все) , Если ваш код содержит информацию о зависимостях, вы сразу узнаете, какой тест вызывает проблему (и в тестовой среде не будут выполняться тесты, которые, несомненно, потерпят неудачу).
Когда вы тестируете многоступенчатый рабочий процесс, это может быть более чистой альтернативой сбросу длинного сценария в одном методе тестирования. Аналогично для тестов UI, которые требуют входа и навигации. – chrylis
как насчет наличия абстрактного модульного тестового класса, который делает это в отдельных функциях? – daydreamer
Это означает, что каждый последующий тест теперь требует шаблона. – chrylis