Зависимости между тест кейсами - зло или нет?

программирование java
,
#1

Народ, почему принято считать, что зависимости между тест кейсами - это зло? Вот пишут “Tests should not depend on each other.”

Например в #testng у меня два теста Test1 и Test2. Один создаёт репорт, второй - удаляет.
Я использую “dependsOnMethods”, то есть Test2 dependsOnMethods = “Test1”
Но меня тут пытаются убедить, что так делать нежелательно.

Я понимаю, что в общем, да - зависимости усложняют структуру тестов, но вот в вышеприведённом случае это вроде бы оправдано.
Или я что-то упускаю?

#2

Конечно. Вы не сможете в случае падения теста с фейлом проверить второй тест. Прекондишн к тесту с удалением лучше сделать в виде какого нибудь sql запроса или что там у вас используется

4 лайка
#3

С другой стороны может второй тест и не должен запускаться если первый не прошел. Тогда оправдано. Но, с точки изоляции проблемы dependsOn вносят шум, усложняют анализ падений.

#4

Нет-нет, такого не должно быть. Тогда это должен быть один тест.

2 лайка
#5

согласен,

если тесты начинают зависить друг от друга, либо:

  1. Переписывайте.
  2. Сносите.
  3. Обьединяйте
#6

Почему не должно быть? :slight_smile: Если остальные тесты по времени прогона будут занимать много времени, то ситуация валидна (правда тут спасает py.test с опцией прерывать прогон на первом падении). А если, конечно, мы берем описаный случай, то у нас зависимость от данных получается, то так делать не стоит.

#7

эм, а запустить сьюты на разных машинах? если уж настолько тесты разрослись

#8

Так, господа из TestNG оправдывают появление dependsOn следующими примерами:

  • To make sure a certain number of test methods have completed and succeeded before running more test methods.
  • To initialize your tests while wanting this initialization methods to be test methods as well (methods tagged with @Before/After will not be part of the final report).

Далее:

In TestNG, we use dependOnMethods and dependsOnGroups to implement dependency testing. If a dependent method is fail, all the subsequent test methods will be skipped, NOT failed.

Иногда нет возможности распределенного тестирования - все идет на одной машине, иногда нужно что-то специфичное подготовить для теста. Вариантов 100500. Главное понимать зачем вы внедряете зависимость - сможет ли человек, пришедший за вами - понять вашу гениальную задумку.

И да, в целом в свое время я ушел на py.test ибо в нем нет явной реализации зависимостей, что не дает юным коллегам наступать на грабли. Ну и по мере работы с py.test появляются все новые и новые плюсы, рекомендую.

1 лайк
#9

py.test и его фикстуры - сила!

1 лайк