We have a project in a private repository which has a single go.mod file at the root of the repo.
To run our tests we call go test --json ./... > test-results.out which runs fine and the output file is in the expected format.
When we run the sonar scanner to feed the test results we get a warning for every single test and the report has no tests:
INFO: Sensor Go Unit Test Report [go]
WARN: Failed to find test file for package github.com/<org>/<name>/code/aws_connection and test TestCreateAWSConnection/Basic_connection
I changed the go package name which is github.com/<org>/<name> here.
In this case we would have the *.test.go and *.go files under the code/aws_connection folder.
We did try to sed the output file to remove the package name so that lines such as:
But we still have no success. There is no documentation on how these lines are interpreted by the go plugin and why the test results are then discarded.
The reports in SonarCloud do show the test coverage but no test results.
After looking at several similar issues in the forums I found out that we needed to add these 2 lines to our sonar-project.properties file:
sonar.sources = .
sonar.tests = .
After that, no more warnings, and the test results showed up.
The documentation for sonar.go.tests.reportPaths does not explain that it depends on sonar.tests:
And there is not much documentation about how sonar.tests impacts the behavior of sonar reports: Automatic analysis & SonarCloud.
Side note. The test results are only reported in our main branch (apparently only long lived branch get them) … I did not realize that they are actually ignored for PRs. It would be very useful to have a quality gate on failed tests in PRs though.
It’s a fair point that the link between sonar.tests and test execution reports isn’t documented. I’ll pass that on to the docs team.
I’m surprised though that setting sonar.sources and sonar.tests didn’t result in duplicate indexation errors. Typically it does, so you should be cautious about applying this fix across the board.
TBH, we’ve had many internal movements over the years to drop test execution reporting altogether. We really feel it’s something that belongs at the CI level, and that if you’ve got falling tests, you really shouldn’t move forward in the pipeline. So I wouldn’t hold my breath on this if I were you.
