# Har taget den ubrugte halvdel af kernen i brug Har taget den halvdel af beskedkernen i brug, som applikationen aldrig havde brugt — backupoverførsel, forsvindende beskeder, redigering og gensendelse af beskeder, verificerede invitationer, proxyer og krypteringspolitik — og kørt hver test mod det rigtige bibliotek uden mocks. september 2026 **Situation.** Klienten brugte omtrent halvdelen af det, beskedkernen tilbyder. Den ubrugte halvdel var ikke obskur — sikkerhedskopioverførsel mellem enheder, forsvindende beskeder, redigering og gensendelse af beskeder, verificerede indbydelseslinks, proxykonfiguration og krypteringspolitikken for en samtale. Hver af dem er en funktion, en bruger ville forvente, og hver af dem var et utestet område af C‑grænsefladen, hvilket er den farligere kendsgerning, for et utestet område af en C‑grænseflade er der, hvor ejerskabsfejlene bor. **Opgave.** Den uudnyttede funktionalitet skulle tages i brug og dækkes af test, og testene skulle køre mod det rigtige bibliotek og ikke mod en erstatning. **Handling.** Reglen, der blev vedtaget, var ingen mocks for kernen. En mock af en C‑grænseflade indkoder udviklerens antagelse om, hvad biblioteket gør, og hver defekt, der er værd at finde her, er et sted, hvor den antagelse er forkert — så når en test baseret på mocks består, beviser det noget om mocken. I stedet opretter testene rigtige konti i midlertidige mapper, kalder det rigtige bibliotek og tjekker, hvad det reelt returnerer, og hver suite rydder op efter sin egen tilstand. Det var det, der gjorde dækningen meningsfuld: at teste sikkerhedskopioverførsel betød at håndtere tilstandsmaskinen i en rigtig overførsel og dens fejlveje, og at teste verificerede indbydelser betød at konstruere det rigtige linkformat og få biblioteket til at fortolke det. Minimumsgrænser for dækning blev sat pr. lag i stedet for som ét tal, med fireogfirs procent for kerneindpakningen, femoghalvfjerds for hjælpefunktioner og femogtres for modeller, ud fra den betragtning, at det lag, der rører rå pointere, bør holdes højest, og at en model, der mest består af lagrede egenskaber, ikke bør polstres med test for at nå et gennemsnit. **Resultat.** Den halvdel af kernen, der tidligere ikke blev brugt, afprøves nu af test mod det rigtige bibliotek, og indpakningen har den højeste minimumsgrænse i projektet. Omkostningen er hastighed og forudsigelighed: test mod det rigtige bibliotek er langsommere end mocks, og de kan fejle af årsager i miljøet, hvilket er prisen for, at de kan fejle af reelle årsager. --- - Rolle: macOS‑applikationsudvikler - Kategorier: [Backend‑udvikling](https://engineer.company/da/categories/backend/), [API'er & integration](https://engineer.company/da/categories/api/), [Automatisering & CI/CD](https://engineer.company/da/categories/automation/), [Driftssikkerhed & backup](https://engineer.company/da/categories/reliability/), [Sikkerhed](https://engineer.company/da/categories/security/), [Test & QA](https://engineer.company/da/categories/testing/) - Ydelser: [Backend- & API‑udvikling](https://engineer.company/da/services/backend-development/), [DevOps & CI/CD‑automatisering](https://engineer.company/da/services/devops-cicd/), [Sikkerhed & adgangsstyring](https://engineer.company/da/services/security-access/)