Har bygget en testsuite til Go, SQL og browseren

Situation. En platform, der holder sin forretningslogik i databasen, har et testproblem, de fleste projekter ikke har. Logikken ligger ikke i det sprog, testframeworket er godt til — den ligger i SQL, bag funktionsgrænser, og SQL er præcis den slags kode, der ender utestet, fordi den er besværlig at teste. Lægger man et Go‑API og en Next.js‑frontend oven på, bliver “de vigtige dele er dækket” stille og roligt til “de dele, der var nemme at dække, er dækket”.

Opgave. Hvert lag skulle have sin adfærd kontrolleret dér, hvor adfærden faktisk hører hjemme, i stedet for at alt blev kontrolleret udefra gennem en browser.

Handling. Fire lag fik fire slags test. Go‑API’et har 981 testfunktioner fordelt på 310 filer. Frontenden har 543 Vitest- og Playwright‑specs, heraf 48 end‑to‑end‑filer og 30 browser‑specs. Databasen har 494 adfærdstestfiler — 116.876 linjer SQL, der kontrollerer resultaterne via 6.654 rejste exceptions — så en stored function bliver testet i databasen og ikke gennem tre applikationslag ovenover. Oven over dem ligger de test, der tester testene: mutationstest med Stryker ødelægger med vilje en linje og fejler, hvis ingen test opdager det, og fast‑check genererer input, som ingen havde tænkt på at skrive ned. En axe‑core‑kontrol kræver nul overtrædelser af WCAG 2.0 og 2.1 på niveau A og AA, hvilket gør tilgængelighed til noget, der får buildet til at fejle, snarere end til et revisionsfund måneder senere. Tærsklerne for testdækning bliver kun hævet. Hele suiten kører som 10 jobs i et workflow på 612 linjer.

Resultat. At ændre noget strukturelt holdt op med at være skræmmende, og det er det eneste, der forhindrer en kodebase af den størrelse i at forkalke. Den ærlige pris er tid — suiten er langsom, den lægger en ekstra byrde på hver eneste ændring, og i den størrelse skal den selv vedligeholdes. Til gengæld får man evnen til at blive ved med at bevæge sig hurtigt, og det er mere værd end de minutter, den tager.