Знакомая ситуация: у вас есть полсотни тест-кейсов, и в каждом из них первые три шага — это авторизация, подготовка тестового окружения или генерация данных. Вы послушно копируете этот блок из кейса в кейс. Но что происходит, когда флоу авторизации немного меняется? Правильно: вам приходится вручную обновлять десятки сценариев. Библиотека раздувается, а риск забыть обновить значительно возрастает.
Чтобы навсегда закрыть эту проблему, в SaveTest реализован механизм Общих кейсов. В этой статье мы детально разберем, как они работают под капотом и как помогают навести порядок в тестовой документации.
Что такое «Общие кейсы»
По сути это переиспользуемые фрагменты тестовых сценариев. Вы описываете типовую последовательность действий один раз и сохраняете ее как общий кейс. Во всех остальных сценариях вы просто оставляете на него ссылку, например <Авторизация под админом>.
Когда тестировщик открывает кейс для просмотра или запускает тест-ран, система на лету подставляет реальные шаги на место этой ссылки. Механизм универсален: он работает как в классических проектах с UI-интерфейсом, так и при подходе «тест-кейсы как код» — в Git-проектах через YAML-файлы, где такие кейсы хранятся в каталогах common-case или .common-case.
Как это устроено
Чтобы не создавать путаницу в реестре, мы реализовали четкое разделение сущностей:
- Специальный набор (suite). Общие кейсы не лежат вперемешку с обычными проверками. Для них создается отдельный «Набор общих кейсов» — он имеет свою иконку и тип в дереве реестра, чтобы вы всегда могли быстро его идентифицировать.
- Только шаги. Общий кейс — это чистая выжимка действий. В нем нет итераций: он содержит исключительно блок «Шаги», который будет транслироваться в другие сценарии.
- Развертка в прогоне. В плане тест-рана общий кейс не выделяется в отдельную задачу. Вместо сухой строки-ссылки <Авторизоваться админом> исполнитель видит полноценный список шагов родительского кейса, внутрь которого органично (но с визуальным отличием) встроены шаги из общего блока.
Как создать и подключить в классическом проекте
Процесс подключения общих кейсов сделан максимально бесшовным.
- Создаем базу. В дереве реестра кликаете правой кнопкой мыши по нужной папке и выбираете «Новый набор общих кейсов». Внутри создаете сам кейс и прописываете ему шаги.
- Линкуем в обычный сценарий. Открываете любой рядовой тест-кейс, переходите в режим редактирования. Нажимаете кнопку «+ Общий кейс» и выбираете нужный из модального окна — там же доступен поиск по наборам.
- Сохраняем. В тексте шагов, предусловий или постусловий появится ссылка формата новый шаг, помеченный синим цветом
Git-проект: создание и подключение (расширение SaveTest для VS Code)
В репозитории с тест-кейсами в YAML общие кейсы лежат отдельно от обычных наборов — обычно в tests/common-case/. После команды инициализации проекта эта папка появляется вместе с tests/test-case/ и tests/attach/. Если использовать визуальный редактор, создание и подключение общего кейса мало чем отличается от классического проекта.
1. Создаем общий кейс. Есть два удобных способа:
- Через проводник: ПКМ по папке common-case → SaveTest: Создать Common Case. Расширение создаст YAML-файл набора с шаблоном, который можно изменить вручную.
- Через визуальный редактор: откройте любой файл из tests/common-case/ (существующий или только что созданный), нажмите иконку визуального редактора в правом верхнем углу. Редактор переключится в режим общего кейса: доступны только название, описание и шаги; кнопка «Добавить тест-кейс» позволяет завести еще один общий кейс в том же файле. Предусловия, постусловия и итерации в этом режиме скрыты.
2. В обоих случаях заполните title и блок steps, затем сохраните файл.
3. Подключаем к сценарию. Откройте test-suite.yaml, включите визуальный редактор и в шагах, предусловиях или постусловиях нажмите «Общий кейс» — выберите файл и нужный кейс. В YAML появится ссылка <Имя общего кейса> и блок метаданных:
3. Подключаем к сценарию. Откройте test-suite.yaml, включите визуальный редактор и в шагах, предусловиях или постусловиях нажмите «Общий кейс» — выберите файл и нужный кейс. В YAML появится ссылка <Имя общего кейса> и блок метаданных:
pre-conditions:
- action: <Предусловие авторизации>
common_cases:
- case_id: "uuid"
name: Предусловие авторизации
path: tests/common-case/common-case.yaml
- action: <Предусловие авторизации>
common_cases:
- case_id: "uuid"
name: Предусловие авторизации
path: tests/common-case/common-case.yaml
Зачем это вашей команде
Внедрение общих кейсов решает сразу несколько инфраструктурных задач QA-отдела:
- Единая точка правки. Меньше дублей. Изменился процесс очистки базы данных — вы правите один общий кейс, и изменения сразу применяются во всех сценариях, где он подключен.
- Забота об исполнителях. Тестировщику, особенно новичку, не нужно лезть в документацию, чтобы вспомнить, что значит шаг «Подготовь стенд». Во время прогона он увидит четкую развернутую инструкцию.
- Прозрачная аналитика. Общие кейсы и их пути в Git и TMS полностью синхронизированы. В аналитике проекта они считаются отдельно от рядовых проверок, показывая реальный, а не раздутый объем тестовой базы.
- Для тимлида это еще и способ упростить онбординг. Новому тестировщику не нужно разбираться в повторяющихся служебных шагах по разным кейсам: общие сценарии формируют единый стандарт выполнения и снижают риск ошибок в первые недели работы.
Если блок шагов повторяется в нескольких сценариях и должен поддерживаться централизованно, это хороший кандидат на общий кейс
Важные нюансы и ограничения
Чтобы инструмент работал предсказуемо, важно помнить несколько правил:
- Подставляются только шаги. Предусловия и постусловия из общего кейса не переносятся.
- Вложенность не поддерживается. Нельзя вложить один общий кейс в другой через UI. Это сделано для сохранения плоской и прозрачной архитектуры тестов.
- Чувствительность к неймингу. Если в git-проекте вы прописали ссылку <...> руками и ошиблись в имени или общий кейс был удален, развертки не будет — исполнитель увидит просто текст.
- Осторожно с переименованием. Если общий кейс переименовали, а в сценариях остались старые ручные ссылки <Имя>, система не сможет корректно развернуть шаги. Поэтому перед переименованием стоит проверить, где именно этот кейс уже используется.
Типичные ошибки
- Вынести в общий кейс слишком большой фрагмент, который потом сложно переиспользовать.
- Использовать неочевидные названия вроде <Подготовка 1> вместо говорящих имен.
- Редактировать ссылки вручную и допускать расхождения в названии.
- Пытаться использовать общий кейс как контейнер для сложной логики, а не для повторяющейся последовательности шагов.
- В Git‑проекте ошибаться в структуре YAML или отступах, из‑за чего файл становится менее предсказуемым в работе.
Практика: с чего начать
Выносите в общие кейсы любые рутинные действия: навигацию по сложным меню, вход в систему с разными ролями, генерацию тестовых данных или финальную очистку среды. Старайтесь давать ссылкам максимально говорящие имена.
И главное правило: перед тем как радикально переписать или удалить существующий общий кейс, учитывайте все сценарии, куда он уже подключен.
Общие кейсы в SaveTest — это инструмент, который превращает поддержку тестовой библиотеки из рутины в управляемый процесс. Один блок шагов для множества сценариев, одна правка — и у команды всегда актуальные инструкции на прогоне.