Inconsistent Branch Coverage When Merging Unit & Functional Tests – BRDA Block Mismatch

SonarQube Server / Community Build
, ,
1

Hi all,

We’re experiencing a coverage inconsistency issue when integrating SonarQube with our JavaScript project using the sonar.javascript.lcov.reportPaths property to provide coverage from both unit and functional test suites.
we are using sonar version: * Enterprise Edition

  • v9.9.6 (build 92038)

Problem:

When running unit tests only, branch coverage is accurate, and all branches in certain if conditions are fully covered.

However, when we add functional test coverage and provide both lcov.info files (from unit and functional test folders) in sonar.javascript.lcov.reportPaths, Sonar reports these same branches as only partially covered — even though the unit tests clearly cover all branches.

Observations:

On inspecting the generated lcov.info files:

  • The unit test coverage includes lines like:
    BRDA:108,11,0,17
    BRDA:108,11,1,18
    BRDA:108,12,0,35

  • The functional test coverage includes:
    BRDA:108,14,0,0
    BRDA:108,14,1,0
    BRDA:108,15,0,0

Even though both test types hit line 108, the branch block numbers differ, so merging both reports causes a mismatch. As a result, SonarQube marks branches as partially or not covered at all.

Root Cause (Suspected):

The problem seems to be caused by inconsistent BRDA block and branch IDs across test runs — especially when the functional tests don’t exercise certain branches. This leads to block IDs being generated differently.

What We’ve Tried:

  • Merging raw .json coverage reports using nyc merge and then generating a single lcov.info from the merged output.
  • Confirmed that block IDs are preserved correctly in .json files but not in the final merged lcov.info.

Ask:

Is there a recommended approach to:

  • Avoid BRDA block mismatches when merging multiple test suites?
  • Instruct SonarQube to prioritize the most complete branch coverage when duplicate BRDA entries are encountered for the same line but with different block IDs?

Any guidance or best practices would be appreciated!

Thanks

Let me know if you want to include SonarQube version, Node version, or test tooling details for better support.

2

Hey @Priyanka_Golla

My gut tells me that if after the merge the branch IDs aren’t consistent, that’s an issue to raise with nyc. This seems like a bug: