Подготовка данных для автотестов
Пост в сторону от менеджерского трека.
Хочу затронуть тему важности архитектуры автотестов в части тестовых данных. Поскольку с UI-тестами всё достаточно понятно, то пост хотел бы посвятить именно backend-тестам (REST API, SOAP). Как правильно подготовить тестовые данные и, главное, как легко их поддерживать в будущем.
Вообще, архитектуре проекта автотестов, как правило, уделяется мало внимания. Берётся самый распространённый фреймворк или библиотека, и без особого проектирования начинается написание методов, которые используя эту библиотеку дергают те или иные эндпоинты. Архитектурные паттерны используются редко, ведь нет задачи построить отказоустойчивое и масштабируемое приложение. Но не буду углубляться в эти дебри, вернусь к тестовым данным. Самый простой способ — подготовить файлы с нужным набором тестовых данных. Однако он прост только для самих тестов: не нужно заморачиваться и продумывать архитектуру — считал из файла, вставил в запрос. Но из-за проблем с вариативностью данных файлы начинают раздуваться или их количество начинает множиться. Ну а если они теряют актуальность (а рано или поздно это произойдёт), то на актуализацию уйдёт очень много времени. Небольшая сводка по плюсам и минусам:
1. Плюсы: ⁃ Быстрый старт. ⁃ Быстрое выполнение тестов. Не тратится время на подготовку данных. Работа с файлами не считается, любой язык достаточно шустро справляется с парсингом JSON, CSV, YAML и т. д. ⁃ Отсутствие внешних зависимостей (от других модулей, БД).
2. Минусы: ⁃ Сложная поддержка вариативности данных. ⁃ Необходимость актуализации. ⁃ Неприменимо в случаях регулярного обновления тестовых сред (или применимо, но с очень большой болью).
Другой подход заключается в использовании API для подготовки тестовых данных. Тут уже появляется некая архитектура, которую нужно заложить, чтобы всё хорошо работало. Сам по себе подход не исключает необходимости наличия статических тестовых файлов, но может способствовать существенному их уменьшению.
Плюсы: ⁃ Большая вариативность. ⁃ Логическая связность. ⁃ Упрощение поддержки в части актуализации. ⁃ Если тесты запускаются по тегам (или как-то ещё избирательно), то благодаря прогону сопутствующих API обеспечивается дополнительная проверка.
Минусы: ⁃ Сложная архитектура требует большего опыта со стороны инженера. ⁃ Увеличение времени и трудозатрат на разработку. ⁃ Увеличение времени выполнения тестов. ⁃ Избыточность при выполнении отдельного теста. Возможны ситуации, когда для проверки одного эндпоинта требуется вызвать ещё пять (цифры взяты из головы).
Рассмотрю ещё один подход — отбор тестовых данных из базы или их генерация. Достаточно хороший подход, который позволяет брать «живые» данные и на них проверять сервисы.
Плюсы: ⁃ Большая вариативность. ⁃ Лёгкая поддержка (если функционал стабилен и нет постоянного изменения схемы). ⁃ Возможность генерации тестовых данных напрямую в базе.
Минусы: ⁃ Дополнительная интеграция с БД. ⁃ Увеличение времени прохождения тестов. ⁃ Не по всем требуемым критериям могут быть тестовые данные. В этом случае требуется усложнять архитектуру и предусматривать возможность генерации нужных тестовых данных.
Как итог, все три подхода имеют свои плюсы и минусы, поэтому я бы рекомендовал миксовать их и заранее закладывать в архитектуру проекта возможность их использования.
