5 ms·
This is the way, but it’s tough to sell “we’re not going to unit test this part” in a professional setting where there are incentives to look more responsible t
by closeparen 4y ago
This is the way, but it’s tough to sell “we’re not going to unit test this part” in a professional setting where there are incentives to look more responsible than thou, directors are looking at unit test coverage reports, etc.
- sanderjd 4y agoYeah I have no qualms about writing mostly-BS unit tests when the existing structure of a project makes it infeasible to write good ones. When in Rome! But when I'm starting from scratch or have a chance to do refactoring, I move toward the "functional core" approach as much as possible.
- therealdrag0 4y agoYou can still get code coverage points with broader tests. I think it’s reasonable to disavow expecting single unit tests for nearly every method on every class with mock/boilerplate/copy-paste hell. However, I would still expect “local integration” unit tests that exercise broader chunks of code and keep code coverage up. So it should be “I don’t need to write a new unit test for this because an existing unit test calls the method that calls this method without it being mocked and you can see it’s covered in the code coverage.”
- closeparen 4y agoCode coverage in Go is on a package level. A test that exercises a handler, controller, and repository can accrue coverage for at most one of them.
- therealdrag0 4y agoHuh. I guess I’ll add that to the list of reasons I don’t like Go.