Design and Implementation of a Code Coverage Solution for the Zhuanzhuan Mobile App

Code coverage is a widely used metric to measure how much of the source code is executed during tests, providing confidence in test completeness and release stability. This article introduces the Zhuanzhuan mobile app's custom code‑coverage solution, outlining its goals, design, and implementation details.

Purpose

Quantify the proportion of code executed to reflect test coverage.

Identify uncovered areas for additional testing.

Analyze uncovered code to assess design rationality.

It is emphasized that coverage is only a measure of test completeness, not a guarantee of defect‑free code.

Solution Selection

Existing public tools (e.g., JaCoCo for Java) were evaluated, but no unified, multi‑language solution fit the team’s needs, prompting a from‑scratch implementation.

Conceptual Design

The smallest unit for coverage is a line of code. By inserting a probe (instrumentation) after each line, the system records execution status while preserving the original app logic.

Implementation Steps

Instrument Android and iOS projects by inserting probe code after each line.

When a probe executes, record the corresponding line’s execution state using a unified data structure.

Upload, receive, and store the coverage data on a backend service, merging results across builds.

Key Challenges and Solutions

Accurate instrumentation : Use ASM for Android bytecode analysis and semantic analysis for iOS to ensure probes do not break existing logic.

Performance impact : Initially instrument only logical branches rather than every line to limit overhead.

Probe Details

Logical branch numbering is generated while traversing class files.

Insertion points are derived from line‑number information in bytecode (Android) or from source traversal (iOS).

Method path = fully‑qualified class name + method name; method signature = MD5 of method bytecode, changing when the method is modified.

Data Storage

Android stores probe results in a BitSet; iOS uses a fixed‑size byte array in memory.

Array length is calculated from the total number of logical blocks (1 byte = 8 blocks).

Reporting Strategy

Data is reported at low‑impact lifecycle moments (e.g., Android activity creation/destruction, iOS app launch/background).

Reported payload includes project name, version, uniqueId (timestamp of methodMapping file), and the bit‑array record.

Data Merging

Coverage from different builds (tags) is merged by performing a bitwise OR on records that share the same method signature.

When method signatures differ, the newer build’s data is taken as the source of truth.

Branch‑level merging is performed across tags within the same development branch, using multithreading for efficiency.

Platform Features

View incremental coverage for specific versions/branches and dependent component projects.

Inspect detailed class‑level coverage within component projects.

Examine logical‑branch coverage per class with real‑time rendering.

Select tag intervals to compute temporary incremental coverage.

Compare two tags of the same version to calculate differential coverage.

Future Plans

Add line‑coverage and method‑coverage dimensions, integrating Git diff to compute coverage for changed code.

Refactor the iOS instrumentation for better performance and reliability.

Introduce more user‑friendly features to improve analysis efficiency and overall experience.

Overall, the custom coverage system provides a unified, cross‑platform way to measure, report, and analyze code execution for the Zhuanzhuan Android and iOS applications.