В наборе автотестов один сценарий должен выполняться с разными ролями пользователя. Что следует изменить в архитектуре, чтобы добавление роли не порождало копию сценария?
Нужно вынести различающиеся значения, включая роль пользователя, в параметры теста, а общий сценарий оставить единственным. Такой подход называют параметризацией или data-driven testing.
Тестовый раннер создает отдельный запуск для каждого набора параметров. В результате сценарий не дублируется, а каждый вариант получает собственный результат, диагностику и статус.
Параметризация появилась как практический ответ на проблему копирования однотипных тестов. При ручном создании отдельных сценариев для каждой роли, набора данных или варианта конфигурации исправление общей логики приходится повторять во многих местах.
Разделение сценария и входных данных позволило переиспользовать проверяемое поведение и одновременно сохранять независимые результаты отдельных комбинаций. Это стало особенно важно при росте автоматизированных наборов и запуске тестов в CI.
Если для каждой роли создавать копию теста, постепенно возникают расхождения: в одном варианте исправляют проверку, в другом забывают обновить подготовку данных или очистку состояния. Количество тестов растет быстрее, чем объем действительно проверяемой логики, а сопровождение становится дорогим.
Если, наоборот, поместить все роли в один тест с большим количеством условных ветвей, ошибка одной роли может скрыть результаты остальных. Такой тест хуже диагностируется и часто дает менее точную обратную связь.
Сначала выделяют неизменную последовательность действий: подготовку контекста, выполнение операции и проверку результата. Затем роли и другие различия представляют как данные: например, имя роли, разрешенные действия, ожидаемый результат и необходимые начальные условия.
Раннер запускает один логический тест отдельно для каждого набора параметров. В отчете должны различаться идентификаторы вариантов, чтобы было понятно, какая именно роль завершилась ошибкой.
Важно не превращать параметризацию в набор скрытых ветвей. Если для разных ролей полностью различаются бизнес-сценарии, их лучше разделить: параметризация подходит для вариантов одной проверки, а не для маскировки разных требований.
Нужно проверять корректность самих наборов данных. Полезно явно исключать недопустимые комбинации, задавать ожидаемый результат как параметр и контролировать, что каждый запуск получает независимое состояние.
Главный компромисс — рост числа запусков. При нескольких измерениях, например роли и типе тарифа, образуется комбинационная матрица. Ее можно ограничивать осмысленными наборами, выделять критические комбинации для каждого коммита, а расширенную матрицу запускать по расписанию; при этом сокращение вариантов не должно быть произвольным и должно опираться на риск.
В системе четыре роли имеют общий сценарий оформления заявки, но различаются доступностью финального действия. Команда создала четыре копии UI-теста, и после изменения формы две копии стали использовать устаревшую подготовку данных.
Рассматривались три варианта. Сохранение копий было самым простым решением, но увеличивало расхождения и стоимость поддержки. Один тест с условными ветвями уменьшал дублирование, однако ухудшал читаемость и диагностику. Параметризованный тест с таблицей ролей сохранил общий сценарий и сделал ожидаемое право на финальное действие явным.
Выбрали третий вариант. Каждый запуск получил отдельный идентификатор роли, а набор параметров включал начальное состояние и ожидаемый результат. В итоге изменение общей последовательности выполнялось в одном месте, а сбой показывал конкретную роль без повторного анализа остальных вариантов.
Цикл обычно создает один результат теста: при падении приходится дополнительно выяснять, на каком элементе произошла ошибка, а последующие варианты могут не выполниться. Параметризация создает отдельный тестовый экземпляр для каждого набора данных, поэтому отчетность, повторный запуск и анализ сбоя становятся точнее.
Если варианты отличаются только входными данными, правами или ожидаемым результатом, параметризация обычно уместна. Если различаются последовательность действий, предварительные условия, используемые компоненты или проверяемые бизнес-правила, объединение скрывает различия и усложняет поддержку; в таком случае лучше иметь отдельные сценарии, переиспользуя общие вспомогательные компоненты.
Нельзя бездумно выполнять полное декартово произведение всех значений. Сначала определяют классы эквивалентности и критические взаимодействия параметров, затем формируют минимальный набор, покрывающий существенные комбинации; полный набор оставляют для более редких запусков, если его стоимость оправдана риском. Выбранные ограничения должны быть документированы, иначе сокращение матрицы может незаметно убрать важный сценарий.