Improving Code Quality with Code Diff and Coverage: Practical Guidance for QA and Developers

Background

Perspective 1: How to guarantee business quality amid growth and change. Perspective 2: How to write unit tests to improve code quality during development. Perspective 3: The role of QA as a quality‑assurance gate. QA participates in code diff, which requires basic code knowledge; early collaboration with developers can help QA grow in this area.

1. Why Do Code Diff & Coverage

1.1 Code Diff

Definition: Comparing two code versions to identify changes.

How to diff:

In Beetle, open the branch details and click the Diff button to select two versions.

In IDEA, view the commit history to see before‑and‑after differences.

When to diff:

During test hand‑off: diff the test branch against the release branch to define test scope.

During testing: diff two successive commits to locate the problematic code.

Pre‑release: perform a full diff to ensure the deployed code matches the tested code.

Summary: Using code diff at different stages helps define test boundaries and speeds up problem resolution.

1.2 Code Coverage

Definition: Measuring how comprehensively tests exercise the code, complementing requirement coverage.

How to measure coverage:

Based on requirements: evaluate test case execution results.

Based on code: use coverage metrics (e.g., JaCoCo) to see which lines are executed.

How to view coverage in Beetle: Deploy the branch to a test machine and click the Coverage button to see full or incremental coverage.

Full coverage: Report generated by JaCoCo for the current deployed version.

Incremental coverage: Covered diff lines ÷ total diff lines – useful for small features.

Which code should be covered?

Basic statements, conditionals (if/else), loops (while, for), switch – each branch should be covered.

try‑catch blocks that only log errors – coverage optional.

Mock data – generally not covered, but discuss with developers.

Fallback data that never runs in normal scenarios – recommended to cover.

Entity getters/setters and utility classes – not required.

Listener/clean‑up code that runs only in production – not required.

Summary: Analyze uncovered code to decide if it belongs to a business scenario; use coverage results to refine test cases, identify missing edge cases, and encourage developers to clean dead code.

2. Requirement Examples

2.1 Mini‑Program Flow Test

Scenario: Verify dynamic list of award details on a mini‑program page.

Data should be sorted by time in descending order.

Display at most 100 items.

When real data is insufficient, fill the gap with randomly selected mock data from Apollo.

Problems discovered:

Award list not sorted correctly.

More than 100 items displayed.

Mock data not shown randomly.

Investigation was done by capturing network traffic, locating the relevant API, and using IDEA’s Ctrl+H to find the getBoostDynamic method.

Solutions:

Apply a descending order sort (e.g., orderByDesc ).

Add a counter in the for loop to stop after 100 items.

Generate a random number inside the loop to vary mock data selection.

Images showing before/after code are included in the original article.

2.2 User‑Tagging Management

Scenario 1: Adding a friend (A) and tagging the friend (B) – the tag should belong to A.

Problem: Tag ownership displayed incorrectly.

Investigation revealed that a single field followWxNumber was used for two different WeChat IDs, causing ambiguity.

Solution: Front‑end logic checks the type value and hides followWxNumber when appropriate, avoiding a backend schema change.

Scenario 2: Adding a friend, tagging, then deleting the friend – a record was missing.

Problem: Only two records appeared instead of three because the same database row was reused; the is_Delete flag was set to 99, and the logic generated only one record for both actions.

Solution: When is_Delete = 99 , generate two separate records – one with create_At (tag) and another with update_At (delete).

3. Using IDEA to Pull Branches & View Commit History

1. Open the project, click Git to fetch the latest code.

2. If updates exist, a popup shows changed files and commit count; click “View Commits”.

3. Switch branches via the branch selector.

4. Double‑click a file to open it, then right‑click and choose “Annotate” to see who changed each line and when.

4. Remote Debugging

1. Open Edit Configurations and add a Remote configuration.

2. Provide a name, the IP of the test/sandbox machine, and the port shown in the SIC platform.

3. Set breakpoints in the code, start the remote debug session, and use Evaluate or Ctrl+U to inspect variable values.

5. Review & Summary

The author, an intern turned full‑time QA, reflects on learning to enter new business domains, read requirements, and shift testing left. They emphasize the importance of reading code, using tools like code diff and coverage, collaborating with developers, and continuously improving both business knowledge and technical skills.