Changes in code coverage reporting in the latest two versions of Go impact total percentages. It's likely related to our usage of ./... which causes all packages to be included. While this is useful for ensuring that all tests are executed, it has a direct impact on how CC numbers are generated.
For example, consider azcore/internal/exported.HasStatusCode. This is exported in azcore/runtime and there's a test for it there. However, since we use ./...both versions are included in CC numbers which means we need to have a test in both packages (i.e. redundant tests) else we'll get a zero for the internal version, dragging down CC numbers.
I believe we can fix this with the -coverpkg flag however it's not clear what that looks like yet.
Changes in code coverage reporting in the latest two versions of Go impact total percentages. It's likely related to our usage of
./...
which causes all packages to be included. While this is useful for ensuring that all tests are executed, it has a direct impact on how CC numbers are generated.For example, consider
azcore/internal/exported.HasStatusCode
. This is exported inazcore/runtime
and there's a test for it there. However, since we use./...
both versions are included in CC numbers which means we need to have a test in both packages (i.e. redundant tests) else we'll get a zero for the internal version, dragging down CC numbers.I believe we can fix this with the
-coverpkg
flag however it's not clear what that looks like yet.