Привет! Пользуюсь Python + Selenium + behave bdd framework для автоматизации.
У меня есть созданный feature файл - функционал “Отправка и проверка тикета”, внутри которого описывается 2 сценария:
В данный момент у меня во всех feature файлах сценарии зависимы друг от друга и выполняются последовательно.
Так ли необходимо сделать сценарии в одном feature фале независимыми?
что случается с вашим тестом 2го сценария, когда первый проваливается? я так понимаю, тоже падает. и таким образом, вы будете просматривать отчеты по 2м упавшим тестах, хотя ошибка была только в 1м.
Я думаю что это не необходимость, но штука которая сильно упрощает жизнь.
Есть 3 ньюанса, почему стоит писать независимые тесты.
Расширяемость сценария.
Предположим, фича изменилась и есть необходимость вставить 3-й сценарий между 1-м и 2-м. Например, тикет теперь должен проходить некое внутреннее ревью. В случае зависимых сценариев это сделать можно, но тяжело и неприятно, поскольку модифицировать придётся как минимум сценарий 2, а то и сценарий 1.
Соответственно, прикиньте кол-во задач такого типа, что я описал, прикиньте разницу по времени между “написать 3-й сценарий и вставить его между 1-м и 2-м” и “написать 3-й сценарий, не парясь зависимостями”.
Минусы: время выполнения автотестов может несколько увеличиться, если выполняются на 1 ноде.
Распараллеливание тестов. Независимые тесты допускают распараллеливание, зависимые - нет. Всё просто.
В случае падения зависимого теста, все, что следуют ниже в дереве зависимостей, падают автоматически. В случае падения независимого теста, падают только те тесты, которые должны. Соответственно, в случае наличия 2-х проблем, например, в тесте A и в тесте B, который зависит от A, Ваши тесты покажут только 1-ю проблему, падение теста B не будет информативным.
В Вашем случае я бы сделал 2 теста:
1-й - без пререквизитов, во 2-м я бы добавил тикет в базу через фабрику и таким образом убрал бы зависимость.
Спасибо за развернутый ответ! Вы убедили меня писать независимые сценарии:+1:
Писать в БД для задания начальных условий для второго сценария - это хорошая практика? Допустим в будущем в проекте поменяется логика отправления тикета и тикет в базу будет попадать в другие столбцы, таблицы
Писать в БД для задания начальных условий для второго сценария - это хорошая практика?
Допустимая, но фабрикой - лучше. В этом случае мы получаем дополнительный уровень абстракции между БД и тестами, который и будем менять в случае изменения структуры БД. Кроме того, фабрики зачастую уже есть, если у Вас на проекте используются юнит-тесты. Почему бы не заюзать готовое решение? 
а что такое фабрика? инструмент какой-то?
юнит тестов на нашем проекте нет
Вы предлагаете в фабрике вызывать методы моделей, которые создают тикет?
Но автотесты у нас являются отдельным проектом, они не имеют доступа к коду проекта, все взаимодействие происходит через браузер.
Или использовать SQL и весь код держать в слое фабрик?
Вы предлагаете в фабрике вызывать методы моделей, которые создают тикет?
Ну, это в идеале. Если идеал совсем недостижим - тогда можно пойти 2-мя путями:
Скопипастить модели. Но будете терять время на поддержке. Такой себе вариант.
Использовать SQL, а фабрики использовать в качестве промежуточного уровня абстракции. Так, как Вы и предложили. Тоже будете терять время на поддержке, но по другой причине.
По сути, оба способа примерно одинаковы. Вопрос только в том, где хочется получить maintenance hell - в SQL или в копипащенных моделях 
Пишу в платиновый тред.
Да, должны.
testomat.io управление авто тестами