Code coverage for Go integration tests

Re:Code coverage for Go integration tests by bhawks on Wednesday March 08, 2023 @11:52PM (#35078422)

I find the value of code coverage goes down when the size of the instrumented codebase goes up. It's helpful for smaller tests as you can eyeball where you may be missing cases but on integration tests you end up getting a high coverage percentage just by bringing up the system and not even asserting anything (I guess it doesn't crash :) ).

If you want to methodically measure integration test coverage it seems more valuable to enumerate all your critical features or user flows and attribute test cases to them.

[ Parent | on HN ]

Re:Code coverage for Go integration tests by gabereiser on Wednesday March 08, 2023 @11:59PM (#35078452)

Proper testing is your issue, not coverage. Coverage is to know where it’s missing. Proper testing (positive AND negative cases) is extremely valuable. Not only to ensure your code works properly, but also as documentation on how to use your APIs.

Integration testing is where most testing cycles fail. It’s also more difficult for the developer because now they need an emulator, a container, or some sandbox to test the integration.

Feature testing is one thing but I’d like to know if the foundation works, that the plumbing is there.

[ Parent | on HN ]