В автотестах почти всегда есть конфиги для подготовки тестовых данных. В нашем случае это были CSV-конфиги для SEO-сервиса: title, h1, meta description, meta robots, canonical.

❌ Как было

Подход выглядел довольно типично:

• конфиг — набор строк с шаблонами и переменными (цены, количество товаров и т.д.) • строки от прогона к прогону не менялись • перед тестами — бэкап SEO-настроек, после — восстановление

Со временем стало понятно, что такая модель хрупкая.

Почему:

• конфиги переиспользуются между тестами и прогонами

• даже при наличии бэкапа нельзя на 100% исключить ситуацию, когда данные не восстановятся

• следующий прогон может проверять уже «загрязнённую» систему

💡 Что изменилось

Подход был пересмотрен на уровне модели работы с данными:

🔹 конфиги формируются динамически перед запуском теста 🔹 шаблоны собираются в коде в зависимости от типа страницы 🔹 значения для подстановок подтягиваются из API 🔹 используется Faker, поэтому каждый конфиг уникален 🔹 взаимодействие с SEO-сервисом вынесено в отдельный Java-клиент

✅ Итог

Что это дало:

✔️ тесты стали независимыми друг от друга ✔️ повысилась стабильность прогонов ✔️ даже при сбое восстановления данных следующий запуск остаётся валидным

Для меня это хороший пример того, как автотесты со временем начинают требовать не только сценариев, но и архитектурных решений.

👉 Подробный разбор кейса — в Telegram: https://t.me/sgindiya/13