Есть отличная удаленная работа для php+codeception+jenkins+allure+docker спецов. 100% remote! Присоединиться к проекту

Должны ли сценарии в рамках одного функционала быть независимыми?

bdd
behave
selenium
python
Теги: #<Tag:0x00007f7b61420228> #<Tag:0x00007f7b614200c0> #<Tag:0x00007f7b6141fe18> #<Tag:0x00007f7b6141fc88>

(hudrogen) #1

Привет! Пользуюсь Python + Selenium + behave bdd framework для автоматизации.

У меня есть созданный feature файл - функционал “Отправка и проверка тикета”, внутри которого описывается 2 сценария:

  1. Пользователь отправляет тикет в теххподдержку
  2. Поддержка отвечает на тикет пользователя.

В данный момент у меня во всех feature файлах сценарии зависимы друг от друга и выполняются последовательно.
Так ли необходимо сделать сценарии в одном feature фале независимыми?


(brbrr) #2

что случается с вашим тестом 2го сценария, когда первый проваливается? я так понимаю, тоже падает. и таким образом, вы будете просматривать отчеты по 2м упавшим тестах, хотя ошибка была только в 1м.

Я думаю что это не необходимость, но штука которая сильно упрощает жизнь.


(Дмитрий Мирошник) #3

Есть 3 ньюанса, почему стоит писать независимые тесты.

  1. Расширяемость сценария.
    Предположим, фича изменилась и есть необходимость вставить 3-й сценарий между 1-м и 2-м. Например, тикет теперь должен проходить некое внутреннее ревью. В случае зависимых сценариев это сделать можно, но тяжело и неприятно, поскольку модифицировать придётся как минимум сценарий 2, а то и сценарий 1.
    Соответственно, прикиньте кол-во задач такого типа, что я описал, прикиньте разницу по времени между “написать 3-й сценарий и вставить его между 1-м и 2-м” и “написать 3-й сценарий, не парясь зависимостями”.
    Минусы: время выполнения автотестов может несколько увеличиться, если выполняются на 1 ноде.

  2. Распараллеливание тестов. Независимые тесты допускают распараллеливание, зависимые - нет. Всё просто.

  3. В случае падения зависимого теста, все, что следуют ниже в дереве зависимостей, падают автоматически. В случае падения независимого теста, падают только те тесты, которые должны. Соответственно, в случае наличия 2-х проблем, например, в тесте A и в тесте B, который зависит от A, Ваши тесты покажут только 1-ю проблему, падение теста B не будет информативным.

В Вашем случае я бы сделал 2 теста:
1-й - без пререквизитов, во 2-м я бы добавил тикет в базу через фабрику и таким образом убрал бы зависимость.


(hudrogen) #4

Спасибо за развернутый ответ! Вы убедили меня писать независимые сценарии:+1:
Писать в БД для задания начальных условий для второго сценария - это хорошая практика? Допустим в будущем в проекте поменяется логика отправления тикета и тикет в базу будет попадать в другие столбцы, таблицы


(Дмитрий Мирошник) #5

Писать в БД для задания начальных условий для второго сценария - это хорошая практика?

Допустимая, но фабрикой - лучше. В этом случае мы получаем дополнительный уровень абстракции между БД и тестами, который и будем менять в случае изменения структуры БД. Кроме того, фабрики зачастую уже есть, если у Вас на проекте используются юнит-тесты. Почему бы не заюзать готовое решение? :wink:


(hudrogen) #6

а что такое фабрика? инструмент какой-то?
юнит тестов на нашем проекте нет


(Дмитрий Мирошник) #7

Это паттерн.
Вот для начала https://ru.wikipedia.org/wiki/Фабричный_метод_(шаблон_проектирования)


(hudrogen) #8

Вы предлагаете в фабрике вызывать методы моделей, которые создают тикет?
Но автотесты у нас являются отдельным проектом, они не имеют доступа к коду проекта, все взаимодействие происходит через браузер.
Или использовать SQL и весь код держать в слое фабрик?


(Дмитрий Мирошник) #9

Вы предлагаете в фабрике вызывать методы моделей, которые создают тикет?

Ну, это в идеале. Если идеал совсем недостижим - тогда можно пойти 2-мя путями:

  1. Скопипастить модели. Но будете терять время на поддержке. Такой себе вариант.

  2. Использовать SQL, а фабрики использовать в качестве промежуточного уровня абстракции. Так, как Вы и предложили. Тоже будете терять время на поддержке, но по другой причине.

По сути, оба способа примерно одинаковы. Вопрос только в том, где хочется получить maintenance hell - в SQL или в копипащенных моделях :slight_smile:


(Oleksandr Khotemskyi) #10

Пишу в платиновый тред.

Да, должны.