TestbarhetTestability

Testbarhet är hur lätt en app kan verifieras av något annat än en människa: ett E2E-test, en CI-pipeline, eller en AI-agent som kontrollerar sitt eget arbete. Den avgörs av om koden och gränssnittet exponerar stabila, entydiga signaler att pröva mot, lager för lager.

Testning sker i lager

En agent som stänger sin utvecklingsloop når efter den snabbaste pålitliga signalen först och klättrar uppåt:

• Typkontroll / kompilator. Snabbast av alla, fångar hela klasser av fel utan att köra något.
• Enhetstester. Ren logik, gränsfall, regressioner.
• Statisk analys / linters. Mönster och regler.
• API- och integrationstester. Endpoints och kontrakt, verifierbara på statuskod och svarsstruktur.
• Bygge. Kompilerar och paketerar det?
• Browserautomation / E2E. Flödet användaren faktiskt möter; här avgör UI:ns adresserbarhet.
• Observerbarhet. Loggar, nätverksanrop och felytor att läsa av (se tracing).

Handtag på varje lager

Samma princip återkommer överallt: exponera en stabil, entydig signal istället för något man måste gissa sig till. För ett UI-element ett accessible name (den hook som fungerar för alla verktyg och för skärmläsare) med data-testid ovanpå för ramverk som kan selektera på det. För ett API ett typat kontrakt, för ren logik en deterministisk assertion, för drift strukturerade loggar istället för fritext.

Varför det räknas

Ju fler lager som ger snabba, entydiga signaler, desto snabbare sluts agentens loop (en typkontroll på millisekunder framför ett browserklick på sekunder) med mindre gissning och färre tokens. Testbarhet skiljer sig från evals: evals mäter kvaliteten i vad en agent producerar, testbarhet hur lätt själva systemet går att pröva.