Scarnox · Blog

Captcha in geautomatiseerde tests: CI groen houden

Je aanmeldformulier heeft een PopularCaptcha. Je end-to-end-suite moet zich aanmelden. Nu staat CI op rood, en de verleidelijke oplossing, de captcha uitzetten in de testbuild, betekent dat de flow die je test niet de flow is die je gebruikers krijgen.

Er zijn meerdere manieren om hieruit te komen. Ze verschillen in hoeveel van de echte flow ze uitoefenen, dus kies de optie die past bij de vraag die je test beantwoordt. Hier zijn de opties, ruwweg van goedkoopst tot meest realistisch.

Scarnox lost vandaag PopularCaptcha op. Andere captchatypen komen binnenkort, dus de oplossingsoptie hieronder geldt alleen voor PopularCaptcha.

1. Testsleutels voor unit- en lokale tests

Veel captcha-aanbieders publiceren testsleutels die altijd slagen. Gebruik ze wanneer je de omgeving beheert en alleen wilt dat het formulier wordt weergegeven en verzonden. Testsleutels oefenen geen echte verificatie uit, en ze helpen niet zodra je een uitgerolde omgeving test die echte sleutels gebruikt.

2. Een omzeiling voor je eigen staging

Sommige teams voegen een geheime header toe die de backend accepteert in plaats van een captchatoken. Het is snel en gratis, maar het is een codepad dat alleen voor tests bestaat, en één verkeerde configuratie verwijderd van productie. Als je het gebruikt, zet het dan achter een omgevingscontrole, maak het geheim lang en willekeurig, en test dat het in productie wordt afgewezen.

3. De verificatieaanroep mocken

Stub het server-side verificatieverzoek in integratietests. Dat is goed om je backendlogica te controleren, zoals wat er gebeurt wanneer verificatie mislukt. Het vertelt je niets over of de frontend het token correct verstuurt, dus combineer het met een van de andere opties.

4. Echt oplossen in staging en smoke-tests

Wanneer je wilt bewijzen dat de echte flow van begin tot eind werkt, met echte sleutels, de echte widget en echte verificatie, haal dan een token op van een solver-API binnen de test. Dit is de enige optie die een kapotte widgetintegratie vangt.

Een Playwright-helper ziet er zo uit:

// Playwright-testhelper
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);
}

Roep hem vlak voor het verzenden van het formulier in de test aan, niet aan het begin van de test. Tokens verlopen binnen ongeveer twee minuten, en een trage stap eerder in de test kan dat tijdvenster opmaken.

Beperk het aantal oplossingen tot een minimum

Een suite die bij elke run een aanmelding doet, kan in een week veel oplossingen opleveren. Houd het aantal laag:

Voor de regels voor opnieuw proberen binnen de helper hergebruik je het beleid uit foutafhandeling en backoff.

Houd de sleutel uit de repo

Sla de sleutel op als CI-secret, met een naam zoals SCARNOX_KEY, en zet hem nooit in de testcode of de fixtures. Als hij lekt, genereer hem dan opnieuw via het dashboard. De oude sleutel werkt meteen niet meer, dus een gelekte sleutel kan niet lang worden gebruikt om oplossingen te draaien.

Gebruik een aparte sleutel voor CI. Als één pipeline zich misdraagt, kun je die sleutel roteren zonder iets anders aan te raken.

Probeer het op je eigen staging

Maak een account aan en begin met gratis proefcredit, zonder creditcard. Koppel de helper eerst aan één smoke-test, controleer dat hij zich schoon aanmeldt, en voeg hem pas daarna toe aan de rest van de suite. Voor wat oplossen op volume kost, zie actuele prijzen.

Wat je moet controleren na het verzenden

Een opgeloste captcha bewijst alleen dat de widgetstap is gelukt. Controleer na het verzenden de dingen die voor de gebruiker tellen: de volgende pagina laadt, het succesbericht verschijnt, en het account of de bestelling bestaat in je database. Een test die stopt bij "geen fout op het formulier" kan slagen terwijl de aanmelding stilletjes faalt in de backend.

Houd de controles dicht bij de zakelijke uitkomst. Controleer de URL, het zichtbare bericht en één record dat de test heeft aangemaakt. Ruim dat record aan het eind van de run op, zodat de volgende run van een bekende staat start.

De smoke-test op schema draaien

Draai de smoke-test met de echte oplossing volgens een schema, bijvoorbeeld eens per dag tegen staging, in plaats van bij elke pull request. Geplande runs vangen wijzigingen op die de site 's nachts heeft doorgevoerd, zoals een nieuwe widgetversie of een verplaatste sitekey, zonder oplossingen aan elke commit te besteden. Waarschuw het team wanneer de geplande run faalt, en houd de suite per commit op de snellere opties.

Volgende stappen