Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The number of executable lines in not-tested source file is no correctly computed #60

Closed
lylex opened this issue Feb 8, 2018 · 7 comments

Comments

@lylex
Copy link

lylex commented Feb 8, 2018

Description

A not-tested source file will over-decrease the code coverage, even if the definitions are all calculated.

Steps to Reproduce

  1. Create a project with two source files(e.g. a.go and b.go)
  2. Write test for a.go(i.e. a_test.go)
  3. Run the calculation, and you will find the coverage is not expected. Each lines in the b.go are calculated in the total lines.

Versions

Versions of your sonar installation (server, sonar-scanner), gometalinter, go and OS.

Sonar Server: 6.5(build 27846)
Sonar-golang Plugin: 1.2.11-rc10
GO: go1.9.2

@danielleberre
Copy link
Contributor

Well, this is the classical behavior: you expect to have 100% coverage when both a.go and b.go are covered by tests.

Or did I miss something?

Would you like to exclude some files from coverage computation?

@lylex
Copy link
Author

lylex commented Feb 9, 2018

@danielleberre Sorry for the confusion, let me explain a little bit more with an example.

Assume we have the following folder:

└── src
└── <test_project>
├── a.go
├── b.go
├── coverage.xml
├── report.xml
├── sonar-project.properties
├── sonar-scanner.properties
└── test.xml

And a.go is,

`package main

import (
"fmt"
)

func main() {
foo()
fmt.Println("vim-go")
}`

while b.go is

`package main

import (
"fmt"
)

func foo() {
fmt.Println("in foo")
}`

After we generated the coverage.xml, report.xml and test.xml, and then run sonar-runner successfully,
we will see the uncovered lines is unexpected.

  Coverage Uncovered Lines Uncovered Conditions
a.go 0.0% 10
b.go 0.0% 9

As we can see, uncovered lines in a.go should be 2, and b.go should be 1.

So, when a certain package contains no test files, each lines of the packages will calculated as uncovered lines, and that is not corrected.

@danielleberre
Copy link
Contributor

ok, I see.

When files are tested, we rely on the coverage file to detect "executable lines", so that information is correct.

When files are not tested, we simply report the number of lines, we do not restrict to executable lines.

@thibaultfalque any idea how to count the number of executable lines in untested files?

@danielleberre danielleberre changed the title Not-tested source file will over-decrease the code coverage The number of executable lines in not-tested source file is no correctly computed Feb 9, 2018
thibaultfalque pushed a commit that referenced this issue Feb 9, 2018
thibaultfalque pushed a commit that referenced this issue Feb 9, 2018
@thibaultfalque
Copy link
Collaborator

6394778

@thibaultfalque
Copy link
Collaborator

We improved the calculation of untested lines. We will publish a release soon.

@thibaultfalque
Copy link
Collaborator

@lylex could you test with the last release ?

@lylex
Copy link
Author

lylex commented Feb 11, 2018

@thibaultfalque I have tried the new release with my project, and I still find something unexpected. I believe that is not the same root cause, so I verify this issue and open #61.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants