SonarCube 98.2% coverage while jacoco gives 100%

SonarQube Cloud
, , , ,
1

Hi everyone,

I’m new to the forum so sorry if this is the wrong section.
I’m using sonarcube community edition version.
I’m really struggling to understand this problem and I think it can be a sonarcube related false positive problem with java

I have the following code as an example:

@Override

	public User findUserById(int id) throws GenericRepositoryException {

		String statement = String.format(userByIdQuery, USER_TABLE_NAME);

		try (PreparedStatement stmt = connection.prepareStatement(statement)) {

			stmt.setInt(1, id);

			ResultSet rs = stmt.executeQuery();

			if (rs.next()) {

				return databaseToUser(rs);

			}

		} catch (SQLException ex) {

			throw (handleDBException(ex));

		}

		return null;

	}

And I’m running tests coverage using jacoco reaching 100% with my tests.
Sonarcube instead gives me a 98.2% of code coverage saying that catch (SQLException ex) instructions are partially covered (1/2 conditions checked only).

image
image669×289 20.7 KB

I have a very similar method that is checked kinda the same way and instead I get no complain about this:

@Override

	public void save(User user) throws GenericRepositoryException {

		if (user == null || user.getUsername() == null || user.getPassword() == null) {

			return;

		}

		String statement = String.format(saveQuery, USER_TABLE_NAME);

		try (PreparedStatement stmt = connection.prepareStatement(statement)) {

			stmt.setString(1, user.getUsername());

			stmt.setString(2, user.getPassword());

			stmt.setInt(3, user.getId());

			stmt.executeUpdate();

		} catch (SQLException ex) {

			throw (handleDBException(ex));

		}

	}

I think this could be an error related to the try-with-resources mechanism, and it may occur when closing the ResultSet, but I’d like to get feedback from someone who knows more.
I would have doubts about my test coverage, but as already said, Jacoco (Eclipse and Maven) shows 100%.

Can someone give me more explanations? Maybe with a way to exclude a specific check from the coverage performed by SonarCube?

Thanks in advance

2

Welcome @Virgula0,

in other context I also observed that code coverage calculation can result in different code coverages, e.g. Visual Studio, Azure DevOps and SonarQube.

As we don’t know your exact test code we can only guess. Propably an SQLException is thrown in one test case - thats 1/2. Is there anonther exception type also thrown in your tests, e.g. in databaseToUser? There the exception should not be catched - case 2.

3

The databaseToUser results to be tested by sonarcube too, anyway I tried to inject and provoke errors on that test but the coverage of sonarcube still sticks at 98.2%

 
 private User databaseToUser(ResultSet rs) throws SQLException {

		return new User(rs.getString(USERNAME_KEY), rs.getString(PWD_DB_KEY), rs.getInt(ID_KEY));

	}
undefined
4

SonarQube bases its coverage metrics directly on your coverage report data. If SonarQube marks a line as partially covered, it’s because the underlying coverage tool—like JaCoCo—reports it that way. Sometimes, you may see 100% line coverage but lower coverage for conditions or branches, which SonarQube also takes into account if reported by JaCoCo.

To confirm, examine your raw JaCoCo XML report to see how it records coverage for specific lines.

If you suspect that JaCoCo is reporting incorrectly, it’s best to reach out to the JaCoCo maintainers for support, as the issue may not be related to SonarQube.

5

First of all, I want to thank you because when you said that SonarCube just takes Jacoco XML output, you pointed me in the right direction.

After hours of debugging, I can say that the problem was actually with try-with-resource, as it was not a coverage calculation error of Jacoco. Eclemma was not helping me in Eclipse since it gives 100% the majority of time and only sometimes not deterministically underlined the catch missing (don’t ask me why).

The fact was that giving the following method.

image
image669×289 20.7 KB

What I was doing was returning from the try-with-resources block, which in Java seems to be an error. In fact, when returning, it seems not to be able to close opened resources automatically (like done instead by defer statements in Go, for example). Thus, leaving it to a correct detection by Jacoco. The error could have been way clearer, but at the end of the day, it was just a language-related issue.

This was enough to fix it:

@Override

	public User findUserById(int id) throws GenericRepositoryException {

		String statement = String.format(userByIdQuery, USER_TABLE_NAME);

		User userToReturn = null;

		try (PreparedStatement stmt = connection.prepareStatement(statement)) {

			stmt.setInt(1, id);

			ResultSet rs = stmt.executeQuery();

			if (rs.next()) {

				userToReturn = databaseToUser(rs);

			}

		} catch (SQLException ex) {

			throw (handleDBException(ex));

		}

		return userToReturn;

	}

Sorry for the spam thread, not related to Sonarcube. Hope this can help someone else in future.

1 Like
6

@Virgula0 as far as I understood try-with-resources, the resources should always close, in regular case or abruptly (exception, return, break, continue). Also in Oracle Tutorial a return is inside the try-with-resources block.

1 Like
7

So it should actually be a bug from Jacoco parser. I’ll try to open an issue on GitHub, let’s see what maintainers say

1 Like
8

Just to let you updated, Jacoco team was already aware of coverage problems regarding try-with-resources usages False positive missing branch coverage when using `try-with-resource` mechanism and return statement within · Issue #1993 · jacoco/jacoco · GitHub

Not that easy to investigate and required manual debugging since they marked a related issue about the problem as a “missing feature“ rather than a bug. But anyway maybe it’s true that a bug is just a feature!

2 Likes
9

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.