There was a technique that existed already where you could use `go test -cover` and the `-o` flag to produce a binary from `go test` rather than actually runnin

There was a technique that existed already where you could use `go test -cover` and the `-o` flag to produce a binary from `go test` rather than actually running tests. So you could build a binary that had coverage enabled. Then when you exercised code paths by running that binary with whatever inputs, coverage would be collected and dumped into some local file. Here's an example of the build step: https://github.com/multiprocessio/datastation/blob/main/runner/scripts/runner_test.build#L3 https://github.com/multiprocessio/datastation/blob/main/runn.... And here's how I'd analyze coverage after using the binary: https://github.com/multiprocessio/datastation/blob/main/runner/scripts/test_coverage.sh https://github.com/multiprocessio/datastation/blob/main/runn.... This analysis actually combined both unit test coverage files with integration test coverage so it gave a pretty good overall indication of code paths covered by any tests. I can't remember where I found this technique but it's been around for a while. This new option is the same thing but a way to `go build` with `-cover` instead of `go test -cover -o $out`? Do I have that right? Another example of doing this from 2019: https://stackoverflow.com/a/55640874/1507139 https://stackoverflow.com/a/55640874/1507139. I'm sure I learned about this from somebody's blog but I can't remember where.