Blop: Tests as code og agentic browser-QA

Blop driver rigtige Playwright-browsere for at verificere din kørende app. Tests lever som .blop.ts-filer i dit repo, og kørsler emitter results.json, events.jsonl, JUnit XML og screenshots. Sådan fungerer det.

Blop er vores agent til at verificere kørende software. Den driver rigtige Playwright-browsere, går gennem det faktiske brugerflow og rapporterer, hvad den fandt. Dette opslag forklarer, hvordan Blop behandler tests som kode, og hvorfor intent-baseret browser-QA tjener sin plads. Dokumentationen ligger på docs.blopai.com, og produktet på blopai.com.

Det problem, Blop løser

Det meste QA brydes ned til to spørgsmål, der er lette at stille og svære at besvare: “virker builden stadig?” og “virker den kørende app stadig for en bruger?” Det første spørgsmål er det, din test-suite besvarer. Det andet er det, Blop besvarer.

End-to-end-tests er tiltænkt at besvare det andet spørgsmål, men i praksis er de skrøbelige, langsomme og dyre at vedligeholde. De går i stykker ved små markup-ændringer, de indkoder et script frem for en forventning, og når de fejler, fortæller de dig, at en selector brød — ikke at brugeren ikke længere kan fuldføre opgaven. Blop tager en anden form: du beskriver, hvad der skal verificeres som intent, og en agent driver en rigtig browser for at finde ud af hvordan.

Tests som kode

En Blop-test er en TypeScript-fil — en .blop.ts-fil — der læses som intent. Den eksporterer agentTests under describe. agent.goto og agent.goal bygger en nummereret mål-liste, som agenten modtager, når runneren når testen. Den er:

Versionsstyret. Testen lever i dit repository, code-reviewet som enhver anden kode, din at redigere eller slette.
Intent frem for selectors. Mål forbliver læselige, når UI’et ændres — ingen skrøbelige data-testid-kæder eller manuelle klik-sekvenser. Agenten finder elementet ud fra, hvad det skal gøre, ikke ud fra en udvalgt selector.
Hævdsætter intent, ikke matches. “kvitteringsnummeret er synligt” er intent; expect(selector).toHaveCount(1) er en skrøbelig match.
Kører ens lokalt og i CI. Én binær dækker blop init, blop test, blop watch, blop list og blop skills.

Dette er “tests as code” i den ligefremme forstand: testen er et program, den lever ved siden af featuren, og den agent, der redigerer featuren, kan også redigere testen. Når Khadim ændrer et flow, kan Blop opdatere testen, der dækker det, i samme ændring.

Rigtige Playwright-browsere

Blop scripter ikke en headless shell og kalder det QA. Den driver rigtige browsere gennem kontrollerede native tools:

Chromium, Firefox og WebKit er alle understøttet, så den samme intent kører på tværs af de engines, dine brugere faktisk bruger.
Kontrollerede tools, ikke script-eksekvering. Agenten driver browseren over Playwright med kontrollerede tools — ingen shell-escapes, ingen vilkårlig script-eksekvering fra siden.
En persistent harness. @blopai/browser-harness understøtter persistente CLI-sessions og containere til lokal og CI-brug.

Pointen ved at bruge en rigtig browser er, at testen verificerer det, en bruger oplever, ikke en mocket tilnærmelse.

Agentic browser-QA

En scriptet end-to-end-test er en optagelse, der enten passer eller fejler. Blop er agentic: den får et mål, driver browseren mod det mål og tilpasser sig, når siden ikke matcher et fast script.

Den læser den side, den får. Når en knap flytter sig, eller et trin tilføjes, finder agenten den ud fra intent, ikke ud fra en forældet selector.
Den genopretter sig efter små ændringer. Et omdøbt label eller et nyt bekræftelsestrin stopper ikke flowet; agenten omplanlægger mod det, den ser.
Den rapporterer fejlen, ikke symptom. Når et flow bryder, rapporterer Blop, hvilket bruger-synligt trin der fejlede, og hvad den fandt i stedet — ikke et stack-trace fra et assertionsbibliotek.

Det er den praktiske begrundelse for, at en agent laver QA frem for et script: agentens tolerance for ændring er præcis det, der gør testen værd at beholde, efterhånden som produktet udvikler sig.

CI-native reporters

Hver kørsel skriver et fast sæt outputs til .blop/:

results.json — en versioneret result-kontrakt, så andre frameworks kan emittere det samme schema, når adapters kommer.
events.jsonl — en struktureret event-stream for kørslen.
JUnit XML — til CI-systemer, der forbruger det.
Screenshots — så et menneske kan se, hvad agenten så ved fejl.

Result-payloaden er en versioneret kontrakt. Adapters, der emitterer det samme schema for andre frameworks, er planlagte, ikke leverede endnu.

Hvordan Blop og Khadim arbejder sammen

Blop og Khadim dækker to halvdele af samme ændring. Khadim redigerer koden og verificerer build og unit-tests. Blop starter den kørende app og verificerer den bruger-synlige adfærd. En typisk ændring forløber sådan:

Khadim redigerer koden og kører deno task build.
Appen startes lokalt eller i CI.
Blop kører de relevante .blop.ts-tests mod den kørende app.
Hvis Blop finder en regression, læser Khadim rapporten og retter enten koden eller opdaterer testen som del af samme ændring.

De to agenter deler den samme definition på færdig: ændringen er ikke færdig, fordi agenten siger det, den er færdig, fordi build er grøn, og det bruger-synlige flow holder.

Aktuel status og hvad der er early access

Vi er eksplicitte om, hvad der er leveret, og hvad der ikke er:

CLI og .blop.ts-runner, browser-harness (Playwright), CI-native reporters — leveret. Disse er arbejdshesten i dag.
Control plane — early access. Når du vil have hosted historik, uploader det samme result-schema til Blop-platformen: fejl clusterer på tværs af kørsler, tests bliver synthetic checks, og agenten kan åbne fix-PR’er. Dette er early access, ikke generelt tilgængeligt; auto-fix er early access, ikke leveret.
Adapters til andre frameworks — planlagt. Result-payloaden er en versioneret kontrakt; adapters, der emitterer det samme schema, er planlagte, ikke leverede endnu.

Blop er fungerende software i dag: rigtige browsere, tests som kode, CI-native reporters. Det hostede control plane er den del, der stadig er early access. Se Blop-produktsiden for den fulde status-tabel.

For redigeringssiden af en ændring, læs Khadim-opslaget. Kontakt os for at tale om, hvordan Blop passer i dit QA-setup.

Vi holder opdateringer faktiske og korte. Dette opslag afspejler Blops aktuelle adfærd, ikke en roadmap.