-
Notifications
You must be signed in to change notification settings - Fork 5
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
Coverage for Java is tracked for lines, while Go is tracked for ranges #193
Comments
even worse... the go coverage report of mode: set
light/validateDate.go:3.51,6.17 2 1
light/validateDate.go:6.17,8.3 1 1
light/validateDate.go:9.2,9.29 1 1
light/validateDate.go:9.29,11.3 1 1
light/validateDate.go:12.2,12.13 1 1
light/validateDate.go:12.13,14.3 1 1
light/validateDate.go:15.2,15.16 1 1
light/validateDate.go:15.16,16.39 1 1
light/validateDate.go:16.39,17.16 1 1
light/validateDate.go:17.16,19.5 1 1
light/validateDate.go:20.9,21.16 1 1
light/validateDate.go:21.16,23.5 1 1
light/validateDate.go:25.8,26.31 1 1
light/validateDate.go:26.31,28.4 1 1
light/validateDate.go:31.2,31.13 1 1 which means that in lines 3-6 there are two statements covered:
But in the Well... internally we just increment the coverage if the |
also the |
in theory there are 16 statements in both implementations, so the correct result must be a coverage of 16 for both of them, not 7 and not 24 |
Java:
Go:
|
Looking at similar implementations in both languages (and tests with full 100% coverage reported by
gotestsum
andmaven
respectively):go
result of
symflower test
:coverage objects (all entries with count > 0): 7
java
result of
symflower test
coverage objects (all entries with count > 0): 24
The text was updated successfully, but these errors were encountered: