OK
Вы никогда не задумывались почему в тест раннерах такая жопная поддержка паралелизации? Потому что в юнит тестах она ничего не дает и только усложняет
Size: a a a
2020 September 23
AZ
На более низком уровне можно проверить сценарии, которые на высоком воспроизвести сложно
AZ
Sergei
тогда к примеру как бы вы обошли ситуацию, не создавая зависимость: если падает тест на логин, то остальные тесты не должны запускаться, т.к. они завязаны на авторизацию?
Не тест на логин, а шаг на логин)
AZ
Ну тест на логин отдельный наверно нужен
S
причем здесь шаг)
AZ
Sergei
тогда к примеру как бы вы обошли ситуацию, не создавая зависимость: если падает тест на логин, то остальные тесты не должны запускаться, т.к. они завязаны на авторизацию?
Ну не важно тест или шаг. Если дальнейшие шаги завязаны на авторизацию - значит мы нашли блокер.
AZ
Либо у нас шаг или тест плохо написан
S
ну это хорошо, но другие тесты пытаются запускаться, а это не нужно)
S
> плохо написан
классика :)
классика :)
AZ
Sergei
ну это хорошо, но другие тесты пытаются запускаться, а это не нужно)
Ну какие тесты пытаются запускаться зависит от наших настроек TestNG или в Дженкинсе
A
Ну если касаться логина, то наверное всякими фикстурами или аналогичным чем-то в других языках это делают. Но возможно пример не самый удачный.
V
А e2e тоже не должны быть зависимые?
AZ
Если сценарии не зависят от авторизации, можно поступить следующим образом. Запускать тесты, где мы тестируем бизнес-логику и разные ветвления с конфигурацией без авторизации, и сделать отдельно тесты с включенной авторизацией и брать из них базовые сценарии.
AZ
Victor
А e2e тоже не должны быть зависимые?
Ну тесты зависимыми делать я не стал. Я бы использовал общие степы.
AZ
@Step и @Test это несколько разные вещи)
S
независимость тестов - это мантра, которая есть потому что легко реализуется, но не кажется ли, логичнее иметь дерево зависимостей тестов, когда тесты, вызывающие внутри себя шаги, уже падавшие в других тестах, помечаются как упавшие или скипнутые. И это в целом не кажется сложным к реализации
A
Основной вопрос. Гипотетически могут ли возникнуть случаи, когда использование зависимых тестов это не зло?
AZ
Sergei
независимость тестов - это мантра, которая есть потому что легко реализуется, но не кажется ли, логичнее иметь дерево зависимостей тестов, когда тесты, вызывающие внутри себя шаги, уже падавшие в других тестах, помечаются как упавшие или скипнутые. И это в целом не кажется сложным к реализации
Ну зависит от специфики проекта, уровня тестирования и наших целей. Тут я универсального рецепта не могу дать.
AZ
Alexander
Основной вопрос. Гипотетически могут ли возникнуть случаи, когда использование зависимых тестов это не зло?
Теоретически как раз случай, описанный Sergei когда нет смысла запускать остальные тесты если базовый тест упал.
AZ
Если тесты разнородные - то нет смысла - будет мешать.