Из чего на самом деле состоит фреймворк для автоматизации тестирования
Сессии и учётные данные
Получение, кэширование и обновление токенов — отдельно для каждого окружения и безопасно при параллельных воркерах.
Тестовые данные
Создание того, что нужно каждому тесту, его изоляция и удаление ровно этого после прогона.
Порядок выполнения и зависимости
Понимание, что должно выполняться раньше чего, и умение пропускать зависимые тесты, а не отмечать их как упавшие.
Плюс отчётность, которую действительно будут читать, конфигурация окружений, политика повторных прогонов и способ отправить нестабильный тест в карантин, не потеряв его. Сами тесты обычно оказываются наименьшей частью.
Скрытая стоимость
Каждую из этих частей пишет тот, кто поднимал фреймворк, — в стиле, до конца понятном только автору. Когда автор уходит, фреймворк превращается в то, что команда боится менять, а набор тестов, который боятся менять, отправляют в карантин, а не чинят.
Когда разработка своего оправдана
Нестандартные требования. Протокол, платформа или требование комплаенса, с которыми не справляется ни одно готовое решение.
Тестирование — основа продукта. Если вы продаёте надёжность, владение обвязкой может быть стратегическим решением.
У вас есть устойчивый ресурс. Не человек на квартал. Владелец на годы.
Когда — нет
Если честная причина в том, что команде нравится строить инструменты или что сравнение готовых решений ничем не закончилось, фреймворк напишут, а потом постепенно забросят. Это типичный случай, и его стоит назвать вслух до первого коммита.
Признаки того, что фреймворк стал продуктом
Полезно держать в голове несколько конкретных признаков, потому что переход происходит постепенно и никто о нём не объявляет.
Кто-то спрашивает, как добавить тест, и объяснение занимает больше двух минут. Новые люди в команде пишут первый тест, копируя существующий и меняя значения, не понимая фикстур под ним. Упавший тест вызывает вопрос, не менялся ли сам фреймворк. Есть файл, который никто не хочет трогать. Работа над фреймворком регулярно появляется в планировании спринта отдельным пунктом.
Любые два признака — и у вас продукт, вся клиентская база которого состоит из одной команды. Само по себе это не плохо: многие компании сделали такой выбор осознанно. Проблема возникает только тогда, когда это произошло без чьего-либо решения, а так обычно и бывает.
Средний путь
Оставьте написанные вручную тесты для тех случаев, которые вы осознанно специфицировали, а широту покрытия отдайте сгенерированным тестам — там задачи сессий, данных, порядка выполнения и очистки решены как часть продукта, а не как ваша инфраструктура.
Терминал
npm install -g @testsprite/testsprite-cli
testsprite setup
Та же настройка доступна в панели TestSprite, если вы не хотите ничего ставить локально. Остальные возможности CLI описаны в репозитории CLI.
Если пайплайн принадлежит другой команде, то GitHub App — путь наименьшего сопротивления: это вебхук, он ничего не меняет в вашем репозитории и срабатывает, когда ваша сборка сообщает, что новая версия развёрнута. Если же вы хотите видеть проверку прямо в репозитории, то шаг GitHub Actions делает именно это.
Что вы получаете вместо того, чтобы строить самим
Те части, которые должны были стать вашей инфраструктурой, приходят как часть продукта. Auto-Authentication поддерживает сессии живыми на протяжении всего прогона, Dynamic Variables переносят значения между вызовами, Dependency Chains выводят порядок выполнения, а Auto-Cleanup удаляет ровно то, что создал прогон. Отчётность, конфигурация окружений и поведение при повторных запусках идут в комплекте, поэтому ничто из этого не превращается в файл, который никто не хочет трогать.
Покрытие генерируется из вашего продукта и уточняется обычным языком — это снимает вторую половину стоимости, ту, где каждый тест должен написать человек, за чьё время конкурируют другие задачи.
Смысл не в том, что строить своё неправильно. Смысл в том, что большинство команд никогда не принимали решения строить, а на девятый месяц обнаруживают, что у них есть продукт с одним внутренним клиентом. Оставить себе тесты, которые вы осознанно специфицировали, и сделать обвязку чужой заботой — это тот вариант, который не обрастает владельцем, которого вы не закладывали в бюджет.
Сколько времени занимает разработка фреймворка?
Первая работающая версия — недели. Версия, которая умеет обновлять сессии, безопасно работать с данными при параллельных запусках и выдавать читаемые отчёты, — кварталы.
Какую часть недооценивают сильнее всего?
Тестовые данные. Создавать их, изолировать и безопасно убирать за собой при параллельном выполнении сложнее, чем всё остальное вместе взятое.
Стоит ли брать существующий фреймворк?
Почти всегда. Строить на готовом фреймворке — не то же самое, что строить сам фреймворк, и незаметно происходит именно второе.
Как понять, что наш фреймворк стал обузой?
Когда его начинают обходить или когда менять его может только один человек. Оба признака поздние, и оба встречаются часто.
Сможем ли мы потом уйти на другое решение?
Тесты редко переносятся. Считайте вложения невозвратными и решайте исходя из этого.
Тесты — это малая часть.
Фреймворк для автоматизации тестирования — это работа с сессиями, тестовые данные, порядок выполнения, отчётность и конфигурация. Стройте свой, когда требования действительно нестандартные и у вас есть владелец на годы, а не на квартал.