# Reached the half of the messaging core the application had never used — backup transfer, disappearing messages, message editing and resending, verified invitations, proxies and encryption policy — driving every test against the real library with no mocks. 2025 **Situation.** The client used roughly half of what the messaging core offers. The unused half was not obscure — backup transfer between devices, disappearing messages, message editing and resending, verified invitation links, proxy configuration and the encryption policy for a chat. Each is a feature a user would expect and each was an untested region of the C interface, which is the more dangerous fact, because an untested region of a C interface is where the ownership mistakes live. **Task.** The unreached capability had to be driven and covered, and the tests had to run against the real library rather than a stand‑in. **Action.** The rule adopted was no mocks for the core. A mock of a C interface encodes the developer's belief about what the library does, and every defect worth finding here is a place where that belief is wrong — so a passing mock‑based test is evidence about the mock. Instead the tests create real accounts in temporary directories, drive the real library, and assert on what it actually returns, with each suite cleaning up its own state. That is what made the coverage meaningful: exercising backup transfer meant handling a real transfer's state machine and its failure paths, and exercising verified invitations meant constructing the real link format and having the library parse it. Coverage floors were set per layer rather than as one number, at eighty‑four percent for the core wrapper, seventy‑five for utilities and sixty‑five for models, on the reasoning that the layer touching raw pointers should be held highest and a model that is mostly stored properties should not be padded with tests to hit an average. **Result.** The previously unreached half of the core is driven by tests against the real library, and the wrapper carries the highest floor in the project. The cost is speed and determinism: real‑library tests are slower than mocks and they can fail for environmental reasons, which is the price of them being able to fail for real ones. --- - Role: macOS Application Engineer - Categories: [Backend Engineering](https://engineer.company/categories/backend/), [APIs & Integration](https://engineer.company/categories/api/), [Automation & CI/CD](https://engineer.company/categories/automation/), [Reliability & Backups](https://engineer.company/categories/reliability/), [Security](https://engineer.company/categories/security/), [Testing & QA](https://engineer.company/categories/testing/) - Services: [Backend & API Development](https://engineer.company/services/backend-development/), [DevOps & CI/CD Automation](https://engineer.company/services/devops-cicd/), [Security & Access Management](https://engineer.company/services/security-access/)