How Finder Enables Precise Code Coverage and Automated Test‑Case Discovery

Background

As projects evolve, business logic and user scenarios become more complex, increasing the cost of maintaining unit tests and coverage data. Manual test‑case review and code review are time‑consuming, error‑prone, and lack quantitative, objective metrics, especially when developers unintentionally introduce hidden changes before code goes live.

Finder Project Overview

Finder is a full‑stack code‑coverage and test‑case discovery system composed of two main modules: one that collects and aggregates coverage data during test execution, and another that analyses the mapping between code changes and test cases to pinpoint the exact regression testing scope.

Architecture Design

Finder is divided into three layers:

Finder Agent (Proxy Layer) : Performs code instrumentation during compilation, gathers coverage data, and extracts source‑level function call information.

Finder Platform (Application Layer) : Provides UI for requirement management, branch management, per‑file coverage heatmaps, API details, test‑case association, and call‑graph visualization.

Finder Server (Core Service Layer) : Hosts the coverage analysis engine and the service‑call analysis engine.

After data collection is set up, testers can run normal business tests; the results are visualized automatically on the platform.

Implementation Details

Code Coverage Module

The module works in two steps: (1) instrument the source code to collect coverage information, and (2) analyse and display the results on a visual dashboard.

Step 1 – Instrumentation and Data Collection

Instrumentation inserts tracking code into the program to record which executable statements are executed. Finder supports both JavaScript and Go with low‑intrusion integration.

For JavaScript, instrumentation is added during the Babel compilation phase and the coverage data is reported via an npm package coverage-report that sends data to the Finder Server.

For Go, the Finder Agent injects instrumentation at compile time, starts an HTTP server that serves coverage data, and the Finder Server periodically pulls the data.

Step 2 – Differential Coverage Statistics

Instead of whole‑project coverage, Finder focuses on the changed code. Git diff is used to isolate modified files, and coverage is calculated only for those lines.

Git diff results are transformed into a line‑indexed array where each element is either empty (no change) or + (changed). Coverage data is also represented as a line‑indexed array with values -1 (non‑executable), 0 (not covered), and 1 (covered). The two arrays are merged, setting non‑changed lines to -1, producing a differential coverage dataset.

Key Issue 1 – Data‑Source Standardisation

Coverage data from different languages has varied structures. Finder normalises all data to a line‑based array, merging statement, branch, and function coverage using a logical AND so that a line is considered covered only when all three dimensions are satisfied.

Key Issue 2 – Maintaining Coverage Accuracy After Code Changes

When code is updated, Finder removes coverage entries for deleted lines and inserts entries for newly added lines, ensuring that historical coverage remains consistent with the current code base.

Key Issue 3 – Single‑Environment Coverage Collection

Because only one staging environment is typically available, Finder offers two solutions: (1) a multi‑lane environment using Per‑Feature‑Branch (PFB) isolation, or (2) functional traceability on a single integration branch by mapping each line to its originating feature branch via git blame and git branch commands.

Related Test‑Case Discovery Module

This module traces the call graph of changed code to identify affected APIs and corresponding test cases. It consists of two phases:

Source Parsing : A CI job parses the abstract syntax tree (AST) and static single‑assignment (SSA) form to extract project Git metadata, function signatures, call relationships, RPC calls, and API definitions.

Data Analysis : The Finder Server merges diff‑derived changed lines with the parsed call graph, performs full‑link tracing from changed functions to API entry points, and marks related test cases. The process handles both direct calls and RPC‑based service interactions, producing a complete cross‑service call chain.

Full‑Stack Microservice Call Chain

To capture end‑to‑end interactions in a distributed system (e.g., a purchase flow spanning gateway, product, order, user, and promotion services), Finder statically analyses RPC definitions, links caller and callee functions, and reconstructs the complete service‑level call graph.

Practical Application

Test‑Submission Phase

Coverage thresholds must be met before code can be submitted for testing.

Customisable coverage rules allow teams to ignore specific files or directories.

Mobile coverage for iOS and Android is supported, exposing platform‑specific gaps early.

Testing Phase

Real‑time coverage dashboards let testers see which changed lines are exercised.

Coverage heatmaps highlight untested regions, guiding additional test creation.

Requirement‑level coverage reports aggregate metrics per feature, aiding risk assessment.

Regression Phase

By correlating changed code ranges with function‑level impact, Finder automatically tags relevant test cases, enabling precise regression testing with reduced effort and higher confidence.

Future Outlook

Planned enhancements include:

Support for additional coverage dimensions such as keyword, related‑code, and high‑risk coverage.

Bug‑trajectory recording that links bugs to exact code changes and coverage data.

A knowledge base that maps test cases to code, offering automated recommendations for test‑case updates.

目录

1. 背景
2. Finder 项目介绍
3. 架构设计
4. 实现方案
    4.1 代码测试覆盖率模块
    4.2 相关用例发现模块
5. 实践应用
    5.1 提测阶段
    5.2 测试阶段
    5.3 回归阶段
6. 未来展望