In October, the mobile app's CI report showed 99.26% line coverage. The number was gratifying, but it was a poor place to start the story. When I joined the consumer engineering team in April, the app had 113 unit-test files and 14 Maestro YAML files. The device flows had existed for years, yet they were not running in CI. A feature could be finished while the work of trusting it still sat ahead of us.
My remit as engineering manager covered mobile, backend and web work. Mobile verification was a particular bottleneck because a change could bring a nearby screen back into scope. People repeated checks near release, often without leaving an executable record for the next change. I wanted the checks to arrive with the implementation, where a developer and reviewer could see what had been exercised.
There is no April coverage percentage in our records. I can't turn 113 test files into an imaginary baseline. The six-month comparison is about the test inventory and the way those tests entered development. The October coverage report is a later measurement of a defined scope.
Tests became part of finishing a change
In May, we began making tests an expectation for changed production code. The agent working on a task had to understand the requirement, implement it, write relevant tests and run the repository checks before presenting the result. The tests were written close to the change, while the intended behaviour was still fresh.
We gave that work some practical support. Jest ran with jest-expo and a shared render helper that supplied providers and routing. Business decisions that did not need a screen could live in pure helpers. Controlled GraphQL responses made it possible to exercise failure states without bringing up the whole application. These choices made a useful test cheaper to write and easier to keep.
The count moved gradually at first: 164 unit-test files at the end of May, 250 in June and 395 in July. It rose to 1,040 in August and 1,669 in September. At the October checkpoint, the inventory contained 2,257 files. That is a substantial record of work. A file can contain one assertion or many, though, and splitting a file changes the count without protecting another behaviour.
The device checks had to run too
The Maestro inventory followed a different path. It stayed at 14 YAML files through April, reached 129 in May and 225 by the end of September. October's snapshot had 404. Those files include leaf flows, shared setup and suite entrypoints, so they do not represent 404 independent journeys.
The more important step was connecting device flows to execution. The first EAS device workflow arrived in May; PR smoke runs and nightly Maestro Cloud runs followed in June. A flow sitting in a folder could now return a result during development. Even then, an inventory count was generous. The October route report found that all 99 non-exempt product routes were reachable through leaf flows in the repository, while only 28 were reached by leaves that CI ran. The gap was visible, which meant we could plan the next work instead of calling the whole app covered.
What October's 99% measured
The October line-coverage report merged results from four Jest shards. It counted 22,903 covered lines out of 23,072 eligible lines within the configured scope. The reported figure was 99.26%. The report also recorded 95.55% branch coverage, a useful reminder to look at decisions and failure paths as well as lines reached.
We had made the coverage scope more explicit. Test helpers, Storybook, development-only code and other excluded files no longer belonged in the production-code denominator. That made the result more useful for the decision it was meant to support. It also means a coverage percentage without its scope is easy to overread. We pinned CI thresholds to the measured October baseline so a later change could not quietly lower that measure.
Coverage still cannot tell a reviewer whether an assertion would catch the bug that prompted a fix. For a regression, I ask for a test that fails with the old defect and passes with the correction. In one review, two defects had slipped through earlier passes. We temporarily reverted their fixes, and both new specifications failed for the original reasons. That was stronger evidence than a green test count.
Nor could the Jest report show what happened on an iOS or Android device. The team brought device runs, screenshots and recordings into review for changed interactions. Those results belonged to the code revision being assessed. They answered questions the coverage report was never designed to answer.
Six months after we started changing the process, the test inventory was much larger and the October coverage measure gave us a demanding CI guardrail. I still wanted the same questions in a review: which behaviour did the tests check, which device paths actually ran, and what remained for a person to assess? The number helped most when it led to those questions.
The figures and engineering decisions are documented in my Beyond the QA Bottleneck case study. I also presented the case study at React Native London on 22 October 2026, hosted at Funding Circle in London; the talk page includes the slides.
