Scarnox · Blog

Utrzymanie zielonego CI, gdy aplikacja ma captcha

Twój formularz rejestracji ma PopularCaptcha. Twój zestaw testów end-to-end musi się zarejestrować. Teraz CI jest czerwone, a kuszące rozwiązanie, czyli wyłączenie captcha w buildzie testowym, oznacza, że testujesz inny przepływ niż ten, z którego korzystają Twoi użytkownicy.

Jest kilka wyjść z tej sytuacji. Różnią się tym, ile prawdziwego przepływu ćwiczą, więc wybierz to, które odpowiada pytaniu, na które odpowiada Twój test. Oto opcje, od najtańszej do najbardziej realistycznej.

Scarnox rozwiązuje dziś PopularCaptcha. Inne typy captcha są wkrótce, więc opcja z rozwiązywaniem poniżej dotyczy wyłącznie PopularCaptcha.

1. Klucze testowe do testów jednostkowych i lokalnych

Wielu dostawców captcha publikuje klucze testowe, które zawsze przechodzą. Używaj ich, gdy kontrolujesz środowisko i potrzebujesz tylko, by formularz się wyrenderował i wysłał. Klucze testowe nie ćwiczą prawdziwej weryfikacji i nie pomogą, gdy testujesz wdrożone środowisko z prawdziwymi kluczami.

2. Obejście dla własnego stagingu

Niektóre zespoły dodają sekretny nagłówek, który backend akceptuje zamiast tokenu captcha. To szybkie i darmowe, ale jest to ścieżka kodu istniejąca tylko na potrzeby testów i jeden błąd konfiguracji od trafienia na produkcję. Jeśli z niej korzystasz, zabezpiecz ją sprawdzeniem środowiska, uczyń sekret długim i losowym oraz przetestuj, że na produkcji jest odrzucany.

3. Mockowanie wywołania weryfikacji

Podmień po stronie serwera żądanie weryfikacji w testach integracyjnych. To dobre do sprawdzenia logiki backendu, na przykład tego, co się dzieje, gdy weryfikacja się nie powiedzie. Nie mówi nic o tym, czy frontend poprawnie wysyła token, więc połącz to z jedną z pozostałych opcji.

4. Rozwiąż captcha naprawdę na stagingu i w testach smoke

Gdy musisz udowodnić, że prawdziwy przepływ działa od początku do końca, z prawdziwymi kluczami, prawdziwym widżetem i prawdziwą weryfikacją, pobierz token z API solvera wewnątrz testu. To jedyna opcja, która wychwyci zepsutą integrację widżetu.

Pomocnik dla Playwright wygląda tak:

// Pomocnik testowy dla 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);
}

Wywołaj go tuż przed wysłaniem formularza w teście, a nie na początku testu. Tokeny wygasają po około dwóch minutach, a wolny krok wcześniej w teście może zużyć to okno.

Ogranicz liczbę rozwiązań do minimum

Zestaw testów, który rejestruje się przy każdym uruchomieniu, może wykonać dużo rozwiązań w ciągu tygodnia. Utrzymuj ich liczbę na niskim poziomie:

Dla zasad ponawiania w pomocniku użyj polityki z obsługi błędów i backoffu.

Trzymaj klucz poza repozytorium

Przechowuj klucz jako sekret CI, nazwany na przykład SCARNOX_KEY, i nigdy nie umieszczaj go w kodzie testów ani w fixture'ach. Jeśli wycieknie, wygeneruj go ponownie z panelu. Stary klucz przestaje działać od razu, więc wyciekły klucz nie posłuży długo do uruchamiania rozwiązań.

Używaj osobnego klucza dla CI. Jeśli jeden pipeline się zachowuje nieprawidłowo, możesz wymienić ten klucz, nie dotykając niczego innego.

Wypróbuj na własnym stagingu

Załóż konto i zacznij od darmowego kredytu próbnego, bez karty. Najpierw podłącz pomocnik do jednego testu smoke, sprawdź, czy rejestracja przechodzi czysto, i dopiero wtedy dodaj go do reszty zestawu. Koszty rozwiązywania przy większej skali znajdziesz w aktualnym cenniku.

Co sprawdzić po wysłaniu

Rozwiązana captcha dowodzi tylko tego, że krok widżetu zadziałał. Po wysłaniu sprawdź rzeczy, które są ważne dla użytkownika: czy ładuje się kolejna strona, czy pojawia się komunikat o sukcesie i czy konto lub zamówienie istnieje w Twojej bazie danych. Test, który kończy się na "brak błędu w formularzu", może przejść, mimo że rejestracja po cichu zawodzi na backendzie.

Trzymaj asercje blisko wyniku biznesowego. Sprawdź adres URL, widoczny komunikat i jeden rekord utworzony przez test. Na końcu uruchomienia usuń ten rekord, aby kolejne uruchomienie zaczynało od znanego stanu.

Uruchamianie testu smoke według harmonogramu

Uruchamiaj test smoke z prawdziwym rozwiązaniem według harmonogramu, na przykład raz dziennie na stagingu, a nie przy każdym pull requeście. Uruchomienia harmonogramowe wychwytują zmiany, które serwis wprowadził w nocy, na przykład nową wersję widżetu lub przeniesiony sitekey, bez wydawania rozwiązań przy każdym commicie. Powiadamiaj zespół, gdy uruchomienie harmonogramowe się nie powiedzie, a zestaw uruchamiany przy każdym commicie zostaw na szybszych opcjach.

Następne kroki