Правила помилок для хибних станів сторінки

Погані запуски мають завершуватися помилкою, а не удавати успіх

Заблокована сторінка - це не успішна сторінка. Якщо запуск упирається у вхід, CAPTCHA, сторінку перевірки, відсутній селектор або взагалі потрапляє не в той стан, результат має завершуватися як хибний стан, а не тихо потрапляти в нормальну історію.

Це захищає і візуальні еталони, і історію перевірок. Інакше зламана сторінка може тихо стати новим погодженим результатом або запустити беззмістовний перегляд знімка, який так і не дійшов до реального стану сторінки.

Де правила помилки потрібні найбільше

Такі правила особливо важливі на сторінках, де чистий знімок може ввести в оману: оплата, реєстрація, документація за захистом, локалізовані сторінки або сценарії, що залежать від файлів cookie і очікувань.

Чим більше контексту потрібно сторінці, щоб дійти до придатного стану, тим важливіше завершувати запуск помилкою на хибних станах, а не змушувати людей здогадуватися з фінального зображення.

Складіть матрицю сигналів для кожного важливого стану

Надійне правило починається не з кольору пікселя, а з доказу стану. Для кожної важливої сторінки запишіть, що має бути присутнім після завантаження, які відомі блокування можуть з'явитися та яка адреса вважається правильною. Це перетворює нечітке 'сторінка виглядає дивно' на перевірку, яку можна повторити.

Найкращий позитивний сигнал - стабільний елемент, пов'язаний зі змістом сторінки: заголовок тарифів, таблиця замовлень, кнопка з відомим призначенням або кореневий контейнер застосунку. Не використовуйте випадковий клас, згенерований збирачем, якщо він може змінитися без зміни інтерфейсу.

• Очікуваний селектор не з'явився після завершення кроків.
• На сторінці з'явився відомий текст помилки, екран входу або перевірка CAPTCHA.
• Фінальна URL-адреса не належить до дозволеного маршруту.
• Сценарій не зміг виконати дію, без якої знімок не має сенсу.

Відокремте помилку запуску від справжньої візуальної зміни

Помилка запуску й візуальна зміна відповідають на різні питання. Помилка означає, що браузер не дійшов до стану, який команда хотіла перевірити. Візуальна зміна означає, що потрібний стан відкрився, але його зображення відрізняється від еталона. Якщо змішати ці випадки, команда почне переглядати CAPTCHA як дизайнерську зміну або пропускати справжню регресію через загальний статус помилки.

Спочатку перевіряйте маршрут, кроки та обов'язковий селектор. Лише після цього створюйте знімок і порівнюйте його з еталоном. Такий порядок робить історію зрозумілою: технічне блокування зупиняє запуск, а зміна вже завантаженої сторінки переходить у чергу візуального перегляду.

Перевіряйте сторінку в одному передбачуваному порядку

Для сторінки оплати, наприклад, недостатньо перевірити, що документ відповів кодом 200. Проксі, екран входу або сторінка захисту також можуть повернути 200. Сценарій має дочекатися заголовка тарифу або форми оплати, переконатися, що немає відомого тексту блокування, і тільки потім створити знімок.

Для авторизованого застосунку позитивним сигналом може бути назва робочого простору або елемент навігації, якого немає на сторінці входу. Якщо сесія застаріла, правило завершить запуск помилкою до порівняння. Команда побачить проблему з підготовкою стану, а не великий диф між застосунком і формою входу.

• Відкрийте сторінку з тим самим регіоном, мовою, файлами cookie й заголовками, що й у робочому сценарії.
• Виконайте кроки до потрібного стану та дочекайтеся стабільного елемента.
• Перевірте відомі хибні стани до створення знімка.
• Збережіть знімок лише після проходження структурних перевірок.
• Додайте до помилки адресу, невдалий крок і назву правила, щоб її можна було відтворити.

Повторюйте тимчасові збої, але не приховуйте постійні

Повтор корисний для короткого мережевого збою, але не має приховувати постійне блокування. Якщо кожна спроба потрапляє на той самий екран входу, ще три повтори лише відкладуть правильний висновок. Зберігайте причину першої помилки й повторюйте лише ті класи збоїв, які справді можуть зникнути без зміни сценарію.

У сповіщенні показуйте сторінку, правило, останню адресу й крок, на якому зупинився браузер. Цього достатньо, щоб власник перевірки відрізнив прострочену сесію від зміненого селектора або захисту на межі мережі. Знімок хибного стану можна залишити як доказ, але не як новий еталон.

Підтримуйте короткий і пояснюваний набір правил

Переглядайте правила разом зі змінами сценарію. Якщо команда перейменувала стабільний атрибут або додала законний проміжний екран, старе правило почне створювати хибні помилки. Оновлення має пояснювати, який новий стан тепер вважається прийнятним і який доказ це підтверджує.

Не додавайте десятки загальних текстових перевірок про всяк випадок. Невеликий набір точних правил легше підтримувати й пояснювати. Почніть з обов'язкового селектора, небажаного маршруту та двох-трьох відомих блокувань. Розширюйте набір після реального інциденту або зміни продуктового сценарію.