ginkgo icon indicating copy to clipboard operation
ginkgo copied to clipboard

No coverage for e2e integration tests

Open aayushchouhan09 opened this issue 3 years ago • 3 comments

I have written some integration tests using Ginkgo and Gomega. When I execute the tests with command :

ginkgo -v --cover --coverprofile=coverage.out ./tests

Tests are passing and the coverage.out file was generated and having a single line content as below:

mode: set

I have used different flags with above ginkgo command, also I migrated from ginkgo/v1 to /v2 to get more flags(for code and coverage analysis) and tried them as well but still the coverage was 0.0% , check the below logs:

Command :

go tool cover -func coverage.out

Output :

total: (statements) 0.0%

Is there anything I am missing as the coverage percentage was miscalculated(0.0% even though we have e2e integration tests present) there?

aayushchouhan09 avatar Jun 01 '22 09:06 aayushchouhan09

hey there - Ginkgo is using go test's support for code coverage. By default this only tracks coverage for the package under test (i.e. the package in which the test files reside). To extend coverage to include other packages you can use the -coverpkg flag to specify additional packages to track coverage for. Depending on the level of abstraction for your integration tests this might/might not work. If you are compiling and integration testing a bunch of different packages then, yes, this should work. If, however, you are integration testing against an external service that you are launching or pointing at then coverage is harder to track.

onsi avatar Jun 01 '22 13:06 onsi

I have tried using this command, still getting the 0.0% coverage :

ginkgo -v --coverprofile=coverage.out --coverpkg=./controllers ./tests

aayushchouhan09 avatar Jun 02 '22 07:06 aayushchouhan09

I'd recommend reading the golang blog post on how coverage works: https://go.dev/blog/cover

basically only packages that are compiled into the test binary can be tracked for test coverage. If you are compiling a separate binary and then launching it and invoking it via an API under test (as one often is during an integration test) then go does not offer any out of the box support for tracking coverage.

In cases like this i've seen some success importing the server code into my test and launching the server from within the tests. That enables coverage tracking of my controllers. But it is no longer, strictly speaking, a true end to end systems integration test.

Unfortunately, I don't believe there is a supported way to instrument a precompiled binary using go's built-in coverage tools. But there's a hacky way to approach it that someone at cloudflare came up with: https://blog.cloudflare.com/go-coverage-with-external-tests/

onsi avatar Jun 02 '22 11:06 onsi