Scarnox · Blog

Капча в тестах: як тримати CI зеленим

Ваша форма реєстрації має PopularCaptcha. Ваш end-to-end набір тестів має проходити реєстрацію. Тепер CI червоний, і спокуслива відповідь — вимкнути капчу в тестовій збірці — означає, що перевіряється не той процес, який бачать ваші користувачі.

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

Scarnox розв'язує PopularCaptcha вже зараз. Інші типи капчі скоро з'являться, тож варіант із розв'язанням нижче стосується лише PopularCaptcha.

1. Тестові ключі для юніт- і локальних тестів

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

2. Обхід для власного staging

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

3. Мокати перевірочний виклик

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

4. Розв'язуйте капчу справжнім чином у staging і smoke-тестах

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

Допоміжна функція для Playwright виглядає так:

// Допоміжна функція для тестів Playwright
export async function solveCaptcha(page) {
  const sitekey = await page.getAttribute("[data-sitekey]", "data-sitekey");
  const r = await fetch("https://api.scarnox.com/api/tasks/create", {
    method: "POST",
    headers: {
      Authorization: `Bearer ${process.env.SCARNOX_KEY}`,
      "Content-Type": "application/json",
    },
    body: JSON.stringify({
      captcha_type: "PopularCaptchaTaskProxyless",
      site_key: sitekey,
      site_url: page.url(),
    }),
  });
  const { errorId, solution, errorCode, errorDescription } = await r.json();
  if (errorId !== 0) throw new Error(`${errorCode}: ${errorDescription}`);

  await page.evaluate((t) => {
    document.querySelectorAll('[name="h-captcha-response"],[name="g-recaptcha-response"]')
      .forEach((el) => { el.value = t; });
  }, solution.token);
}

Викликайте її безпосередньо перед відправкою форми в тесті, а не на початку тесту. Токени спливають приблизно за дві хвилини, і повільний крок раніше в тесті може з'їсти це вікно.

Тримайте розв'язання до мінімуму

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

Правила повторів усередині допоміжної функції візьміть із обробки помилок і backoff.

Тримайте ключ поза репозиторієм

Збережіть ключ як секрет CI з назвою на кшталт SCARNOX_KEY і ніколи не додавайте його в код тестів чи фікстури. Якщо він витече, перегенеруйте його в панелі керування. Старий ключ одразу перестане працювати, тож витеклий ключ не можна буде довго використовувати для розв'язань.

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

Спробуйте на власному staging

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

Що перевіряти після відправки

Розв'язана капча доводить лише те, що крок із віджетом спрацював. Після відправки перевіряйте те, що важливо користувачу: завантажується наступна сторінка, з'являється повідомлення про успіх, а обліковий запис або замовлення існує у вашій базі даних. Тест, який зупиняється на «на формі немає помилки», може пройти, тоді як реєстрація тихо провалюється на бекенді.

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

Запуск smoke-тесту за розкладом

Запускайте smoke-тест із справжнім розв'язанням за розкладом, наприклад раз на день проти staging, а не при кожному pull request. Запуски за розкладом ловлять зміни, які сайт зробив за ніч, наприклад нову версію віджета або змінений sitekey, і не витрачають розв'язання на кожен коміт. Сповіщайте команду, коли запуск за розкладом падає, а набір для кожного коміту тримайте на швидших варіантах.

Наступні кроки