Hopp til innhold

Tok i bruk den halvdelen av meldingskjernen applikasjonen aldri hadde brukt — overføring av sikkerhetskopier, forsvinnende meldinger, redigering og ny sending av meldinger, verifiserte invitasjoner, proxyer og krypteringspolicy — og kjørte hver test mot det ekte biblioteket uten mocks.

halvparten av kjernen applikasjonen aldri hadde brukt

Situasjon. Klienten brukte omtrent halvparten av det meldingskjernen tilbyr. Den ubrukte halvparten var ikke obskur — overføring av sikkerhetskopier mellom enheter, forsvinnende meldinger, redigering og ny sending av meldinger, verifiserte invitasjonslenker, proxy‑konfigurasjon og krypteringspolicyen for en samtale. Hver av dem er en funksjon en bruker ville forvente, og hver av dem var et utestet område av C‑grensesnittet, og det er det farligste av de to, fordi et utestet område av et C‑grensesnitt er der eierskapsfeilene bor.

Oppgave. Funksjonaliteten som ikke var nådd, måtte kjøres og dekkes av tester, og testene måtte kjøre mot det ekte biblioteket i stedet for en erstatning.

Handling. Regelen som ble innført, var: ingen mocker for kjernen. En mock av et C‑grensesnitt koder inn utviklerens oppfatning av hva biblioteket gjør, og hver feil som er verdt å finne her, er et sted der den oppfatningen er feil — så en mockbasert test som består, er bevis om mocken. I stedet oppretter testene ekte kontoer i midlertidige kataloger, kjører det ekte biblioteket og sjekker hva det faktisk returnerer, og hver suite rydder opp sin egen tilstand. Det er det som gjorde testdekningen meningsfull: å teste overføring av sikkerhetskopier betydde å håndtere tilstandsmaskinen til en ekte overføring og feilveiene dens, og å teste verifiserte invitasjoner betydde å konstruere det ekte lenkeformatet og la biblioteket tolke det. Minstegrenser for testdekning ble satt per lag i stedet for som ett tall, på åttifire prosent for kjernewrapperen, syttifem for hjelpekode og sekstifem for modeller, ut fra resonnementet at laget som berører rå pekere, bør holdes høyest, og at en modell som stort sett består av lagrede egenskaper, ikke bør fylles opp med tester for å nå et gjennomsnitt.

Resultat. Den halvparten av kjernen som tidligere ikke var nådd, kjøres nå av tester mot det ekte biblioteket, og wrapperen har den høyeste minstegrensen i prosjektet. Prisen er fart og determinisme: tester mot det ekte biblioteket er tregere enn mocker og kan feile av årsaker i miljøet, og det er prisen for at de kan feile av ekte årsaker.

Ett stykke av en lengre oversikt — og den ligger i sin helhet her.

Hver oppføring er skrevet på samme måte: situasjonen, oppgaven, hva vi gjorde, og hva som endret seg.

Se hele oversikten