Структурирование кода: Precondition Class или расширенный TestBase class

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

Я прочла тред Какой должна быть идеальная структура проекта автотестов?, но все же остался неясным один момент.
Думаю над тем, как мне лучше организовать структуру своего проекта. Вопрос в следующем:
куда стоит включать повторяющиеся шаги теста - в Precondition Class (утилс класс) или в TestBase class.

Например, у нас есть джорни, где юзер проходит/заполняет:

  1. форму регистрации
  2. страницу верификации имейла
  3. страницу выбора своего работодателя
  4. странницу ввода id-шника
    все действия последовательны, т.е. шаги идут один после другого

Я создала 4 отдельные пейджи для каждого из шагов с набором элементов/методов, присущих ей. Также создала Test Base класс со стандартными методами SetUp/TearDown, где бразуер инициализируется и удаляется соответственно.
И вот, например, в тестовом классе ‘страницы верификации имейла’ у меня в каждом тесте сначала выполняется шаг1. А в классе с тестами “странница ввода id-шника” в каждом тесте мне нужно в любом случае сначала пройти первых 3 шага, т.е. я уже пишу много дублирующихся строк.
Вопрос в том, куда мне вынести дублирующиеся шаги: в отдельный класс Preconditions либо же сделать TestBase абстрактным и имплементировать его для каждого тестового класса (т.е. для шага 4, я буду инициализировать браузер и проходить первые 3 шага в SetUp методе).

Надеюсь, понятно обрисовала ситуацию:slight_smile:
Спасибо всем заранее)

1 лайк
#2

Лично для меня оба варианта выглядят не очень приемлемыми. Выносить в базовый класс прекондишены, специфичные для фиксированного сценария (набора) - решение совсем не универсальное. Т.е. если вам потребуется выполнить похожий финт для другого набора тестов, придется велосипедировать. Что в итоге еще усложнит и читабельность, и смысловую нагрузку BaseTest класса. Помимо этого, вы уже зарезервировали данный класс под задачи управления браузером. Следовательно, тестовой логики тут не должно быть. Иначе грань между фреймворком и доменным слоем просто сотрется. И ваш код рано или поздно превратится в спагетти.

У утилитных классов так же несколько иное предназначение. В ситуации, когда вы следуете более или менее ООП принципам, объединение логических цепочек разных страниц лучше сокрыть за фасадом (см. соответствующий паттерн), а не утилитным классом.

3 лайка
#3

шаги и их комбинации в тестах могут дублироваться если их логика инкапсулирована

  • меньшее зло дублировать 1ну строку с вызовом шаг 1
  • большее зло создавать неповоротливую структуру путем наследования всего и вся или генерации большого кол-ва утилит классов

если для ряда тестов общие 3 шага создайте объединяющий и используйте его. объединяющий должен вызывать готовые шаги, а не дублировать их логику

2 лайка
#4

да, про базовый класс вы правы - нужно отделять управление браузером от шагов самого теста, не подумала об этом.
про фасад читаю
Спасибо!

#5

у меня на проекте джорни очень длинные - порядка 20-25 шагов и я тестирую функционал каждой страницы последовательно.
Т.е. когда мне нужно будет тестировать финальный дэшборд на 26м шаге, то сначала нужно будет 25 шагов сделать как pre-condition, а затем сам тест шагов 1-10, что не ок, как по мне.

#6

Не забываем отмечать полезные ответы и посты, решающие поставленную задачу:

#7

я бы рассмотрел вариант генерации предусловий более простым путем нежели повторение 26 шагов.
Например, готовить сразу окружение через API/БД и сразу переходить на dashboard. Почему это невозможно?

1 лайк
#8

А я не говорила, что это невозможно :slight_smile:
Создание предусловий через API - это в планах пока. А вот про генерацию юзеров заранее и хранение их в базе (либо в csv в самом проекте) я не думала.
Спасибо вам!