Måler hvor mye av koden som faktisk kjøres av de automatiske testene. Lav dekning betyr at store deler av systemet endres uten at noe fanger opp feil.
Krever tilgang til kildekoden. For et leverandørlåst system må leverandøren kjøre den.
Hva den avdekker
Hvilke deler av koden som er testet og hvilke som ikke er det. Kritiske deler uten dekning er der endringer er farligst — og der AI-assistert endring uten tester er mest risikabelt.
Slik kjører du den
De fleste testrammeverk gir dekning med et flagg (f.eks. `jest --coverage`). Kjør det, og se på hvilke moduler som er røde. Ikke jag 100 % — sikt på god dekning av det som betyr noe: forretningslogikk, betaling, tilgangskontroll.
Slik tolker du resultatet
Høy dekning garanterer ikke gode tester — man kan «dekke» kode med tester som ikke sjekker noe. Tallet er et signal, ikke et mål i seg selv. Fallgruve: å gjøre dekningsprosenten til et krav som fylles med meningsløse tester.
AI-perspektiv
Dette er kanskje det viktigste sikkerhetsnettet i AI-æraen. Når AI endrer kode raskt og selvsikkert, er testene det som fanger at noe stille ble ødelagt. AI kan dessuten skrive testene selv — så den lave dekningen som før var en unnskyldning, er det ikke lenger.
Har dere et eksisterende system dere lurer på tilstanden til? Mange av disse analysene kan kjøres utenfra, uten å røre koden. DOPS gjennomgår ytelse, sikkerhet og teknisk gjeld i systemer dere allerede eier — og sier ærlig fra om hva som haster og hva som kan vente.
Snakk med DOPS