Автотесты для критичных сценариев магазина (E2E)

Релиз выкатили в пятницу, а в понедельник выясняется, что кнопка «Оформить заказ» неделю не работала — и никто не заметил, пока не упали продажи. Классическая история магазина без автотестов: каждое изменение — это лотерея, потому что вручную проверять весь путь оформления после каждой правки невозможно, а именно там теряются деньги.

Эта статья — о том, как покрыть E2E-автотестами критичные сценарии магазина на 1С-Битрикс: корзину, оформление, оплату и обмен с 1С, чтобы релизы не ломали продажи. Разберём, что тестировать в первую очередь, как проверять оплату без реальных платежей и как встроить тесты в CI. Организовать процессы вокруг этого помогает аудит и оптимизация.

Почему магазину нужны автотесты

Магазин — это система, где ломается незаметно самое дорогое. Ошибка в оформлении или оплате не выдаёт себя баннером «всё сломалось» — покупатель просто не может завершить заказ и уходит. Пока проблему заметят по проседанию выручки, могут пройти дни, а деньги уже потеряны.

Ручное тестирование не спасает от регресса: проверять один и тот же путь оформления после каждого релиза вручную дорого и ненадёжно — человек устаёт, торопится и пропускает. Автотесты решают именно эту задачу: они прогоняют критичные сценарии за минуты, одинаково внимательно каждый раз, и сигнализируют о поломке до того, как её увидит клиент. Это не замена ручному QA, а его дополнение на самом важном участке.

Что такое E2E и где его место

Тесты бывают разного уровня, и для магазина важно понимать, какой что даёт.

E2E (end-to-end) гоняет реальный браузер по настоящему интерфейсу: открывает каталог, добавляет товар, оформляет и оплачивает — ровно как это делает покупатель. Именно поэтому для магазина он самый ценный: ловит поломки, которые видит клиент, даже если каждая функция по отдельности «работает». Юнит- и интеграционные тесты дополняют его снизу, но начинать стоит с E2E критичных путей.

Какие сценарии критичны

Автоматизировать всё сразу — верный способ утонуть. Приоритет расставляют по деньгам: сначала то, что, сломавшись, останавливает продажи.

1. Добавление в корзину. Товар из каталога и карточки попадает в корзину с верной ценой и количеством.
2. Оформление заказа. Заполнение данных, выбор доставки и оплаты, создание заказа.
3. Оплата. Переход к платежу и корректный статус заказа после него.
4. Авторизация и профиль. Вход, регистрация, подстановка сохранённых данных.
5. Повторный заказ. Наполнение корзины из истории для постоянных клиентов.

Это критичный путь выручки. Второстепенные функции — фильтры, сортировки, вспомогательные формы — покрывают позже. Правило: сначала автоматизируйте то, что стоит денег при поломке, а не то, что проще всего протестировать.

Тестирование корзины и оформления

Корзина и оформление — сердце критичного пути, и здесь E2E-тест приносит максимум пользы. Хороший сценарий проходит весь путь и проверяет не только «дошёл до конца», но и корректность данных на каждом шаге.

• Цена и количество. В корзине верная цена, работает изменение количества и удаление.
• Скидки и правила. Промокоды, пороги, скидки применяются корректно.
• Шаги оформления. Доставка, оплата, адрес выбираются и сохраняются.
• Создание заказа. Заказ создаётся с правильным составом и суммой.
• Граничные случаи. Пустая корзина, товар кончился, невалидные данные.

Проверка граничных случаев особенно важна: именно на них магазины ломаются тише всего. Аккуратную серверную логику, которую проверяют такие тесты, удобно строить через D7 ORM, где поведение предсказуемо и легче тестируется.

Оплата на тестовом контуре

Оплату нужно тестировать, но без реальных денег. У почти всех платёжных провайдеров есть тестовый режим и песочница с фейковыми картами, где можно прогнать и успешный, и неуспешный платёж.

Сценарий такой: тест доходит до платёжной страницы, выполняет тестовый платёж и проверяет, что заказ получил правильный статус — «оплачен» при успехе, «ожидает оплаты» или «отменён» при неуспехе. Отдельно стоит проверить возврат покупателя на сайт после оплаты и корректную обработку колбэка от провайдера. Про безопасность интеграционного слоя, через который приходят такие уведомления, мы пишем в статье про REST, вебхуки и безопасность.

Проверка обмена с 1С

Обмен с 1С — одно из самых хрупких мест магазина: меняются форматы, ломаются выгрузки, расходятся остатки. Поэтому его проверка ценна, но её выносят на тестовый контур с песочницей 1С, а не на боевую учётную систему.

• Уход заказа. Заказ с сайта корректно попадает в обмен с нужными данными.
• Приход данных. Остатки, цены и статусы приходят и применяются верно.
• Форматы CommerceML. Данные соответствуют ожидаемой структуре.
• Обработка ошибок. Сбой обмена не роняет сайт и логируется.

Полноценный E2E обмена сложнее браузерного теста, ближе к интеграционному. Но даже базовые проверки формата и доставки данных резко снижают риск «тихой» поломки обмена, которую иначе замечают только по расхождению остатков. Такую логику часто оформляют как отдельный модуль, который проще покрывать тестами.

Тестовые данные и изоляция

Автотесты создают заказы, регистрируют пользователей, меняют состояние — и если делать это на «живых» данных, тесты быстро загрязнят базу и начнут мешать друг другу. Поэтому важна изоляция тестовых данных.

• Отдельные тестовые товары и пользователи. Помеченные, легко отличимые от реальных.
• Подготовка и очистка. Тест сам создаёт нужное состояние и убирает за собой.
• Независимость. Тесты не зависят от порядка запуска и данных друг друга.
• Обезличенные данные. На стенде нет реальных ПДн клиентов.

Изоляция — то, что отличает набор тестов, которому доверяют, от набора, который «иногда падает непонятно почему». Запускают их на staging или отдельном стенде, похожем на бой, но с тестовыми реквизитами. Про организацию таких окружений — в разборе staging-окружения и деплоя.

Автотесты в CI и деплое

Тесты приносят пользу, только когда запускаются автоматически и вовремя — до выкатки на бой. Место им в конвейере CI/CD: при каждом изменении перед деплоем прогоняются критичные сценарии, и если что-то сломалось, релиз останавливается.

1. Триггер по изменению. Тесты запускаются при пуше и перед выкаткой.
2. Прогон на стенде. Сценарии гоняются на staging с тестовыми реквизитами.
3. Блокировка при падении. Красные тесты не пускают релиз на production.
4. Понятный отчёт. Видно, какой сценарий и на каком шаге упал.

Так регресс ловится до боя, а не покупателем. Это замыкает картину надёжной разработки: код в git, окружения, деплой и тесты работают как единый механизм. Полный разбор конвейера — в статье про CI/CD и деплой в Битрикс.

Как не сделать тесты хрупкими

Главная причина, по которой команды бросают автотесты, — хрупкость: тесты падают от каждого пустяка, им перестают доверять, а потом отключают. Этого можно избежать дисциплиной написания.

• Устойчивые селекторы. Привязка к data-атрибутам, а не к случайным CSS-классам вёрстки.
• Явные ожидания. Ждать появления элемента, а не «спать» фиксированное время.
• Изоляция данных. Тест не зависит от чужого состояния.
• Минимум лишних проверок. Тест проверяет суть сценария, а не каждый пиксель.

Правильно написанный E2E-тест падает, когда реально что-то сломалось, а не когда дизайнер поменял отступ. Хрупкость — это следствие небрежности, а не неизбежное свойство E2E. Один надёжный тест ценнее десяти, которым не верят.

С чего начать внедрение

Соблазн «покрыть всё сразу» почти всегда заканчивается заброшенным набором хрупких тестов. Разумный путь — начать с малого и наращивать.

1. Один сквозной сценарий. Путь от каталога до оплаты — самый важный.
2. Надёжность. Довести этот тест до стабильного состояния, которому доверяют.
3. Встроить в CI. Запускать автоматически перед выкаткой.
4. Расширять по приоритету. Добавлять сценарии из списка критичных путей.

Так вы получаете пользу с первого рабочего теста и наращиваете покрытие управляемо. Это тот же принцип итеративности, что и в остальной разработке: маленький надёжный шаг лучше большого рискованного.

Частые ошибки

• Тестировать всё сразу. Огромный набор хрупких тестов, который забрасывают.
• E2E на production. Тесты создают заказы и портят боевые данные.
• Оплата на боевом шлюзе. Реальные списания вместо песочницы.
• Хрупкие селекторы. Тесты падают от любых правок вёрстки.
• Нет запуска в CI. Тесты есть, но их забывают гонять — пользы ноль.
• Игнор граничных случаев. Проверяют только «счастливый путь».
• Реальные ПДн на стенде. Тестовые данные с настоящими контактами клиентов.

Чек-лист покрытия

1. Критичный путь покрыт. Есть E2E на корзину, оформление и оплату.
2. Оплата в песочнице. Тесты платежей идут на тестовых реквизитах.
3. Обмен проверяется. Уход заказа и приход остатков тестируются на песочнице 1С.
4. Данные изолированы. Тестовые товары и пользователи, очистка за собой.
5. Запуск в CI. Тесты гоняются автоматически перед выкаткой.
6. Красный блокирует релиз. Падение тестов останавливает деплой на бой.
7. Тесты стабильны. Падают по делу, а не от правок вёрстки.
8. Покрытие растёт. Сценарии добавляются по приоритету, а не хаотично.

Вывод

Автотесты критичных сценариев превращают релизы из лотереи в контролируемый процесс. E2E-тесты проходят путь покупателя от каталога до оплаты и ловят именно те поломки, которые стоят денег, — до того, как их увидит клиент. Для магазина это самый прямой способ перестать «узнавать о сломанной кнопке оформления по проседанию выручки».

Начинайте с одного надёжного сценария на критичном пути, тестируйте оплату и обмен на песочницах, изолируйте данные и запускайте тесты в CI перед выкаткой. Не гонитесь за полным покрытием сразу — один работающий тест ценнее сотни хрупких. Встроенные в разработку вместе с окружениями и деплоем, автотесты делают развитие магазина быстрым и спокойным, потому что каждый релиз проверяется машиной, а не надеждой.