How to include *_test.go files in coverage reports
Clash Royale CLAN TAG#URR8PPP
How to include *_test.go files in coverage reports
I would like to know if there is a way that I can generate a coverage report that also includes statements covered on the tests themselves.
Regarding the merits of doing such a thing, I would like to see that my tests are as useful as the rest of my code. I've become accustomed to including my test code coverage in python and this is something I find helpful.
Update for clarification:
People seem to think I'm talking about testing my tests. I'm not. I just want to see that the statements in my tests are definitely being hit. For example, code coverage on a function in my application might show me that everything's been hit, but it won't necessarily show me that every boundary has been tested. Seeing statements lit up in my test sources show me that I wrote my test well enough. Yes, better factored code shouldn't be so complex as to need that assurance, but sometimes things just aren't better.
Like I said before, I can see my statements hit in coverage reports from python test sources by including them in the coverage report, and I like that. It's assuring and comforting IMO. It also shows me if I have dead wasteful tests. Code coverage is not the same thing as unit testing.
– andyortlieb
Aug 9 at 13:49
They're not the same thing, one is a measure of the other. Code coverage is a measure of how much real code is exercised by your tests, not a measure of how much test code is executed.
– Adrian
Aug 9 at 13:56
Another things I failed to clarify is that I'm talking about visual code coverage, specifically the HTML report. I don't really care so much about percentage of code covered as much as certain pieces that I expect watch light up while writing tests. While there shouldn't be such messy code that I have conditionals in my tests it can happen at times. I like to see that my statements are being hit. Again, I do this in my python py.test HTML coverage reports and I find it very useful, to show that my tests aren't unreachable, etc.
– andyortlieb
Aug 9 at 16:00
End result is the same: that is not supported natively by the Go toolchain, and recommending third-party tools is off-topic for Stack Overflow.
– Adrian
Aug 9 at 16:07
2 Answers
2
I'm not sure I understand the reasoning behind this.
Unit tests, especially in Go, should be simple and straight-forward enough that by just reading them you should be able to spot if a statement is useless.
If that is not the case, maybe you are implementing your unit tests in a way that is too complicated?
If that is the case, I can recommend checking table-driven tests for most cases (not suited for most concurrency-heavy code or methods that depend a lot on manipulating the state, though) as well as trying out TDD (test-driven development).
By using TDD, instead of building your tests in order to try to cover all of your code, you would be writing simple tests that simply validate the specs of your code.
This would be a great answer if i was asking about how to write tests. What I'm asking for is whether a specific feature parity exists for go's coverage profile as does with py.tests's for example.
– andyortlieb
Aug 9 at 16:02
There is no way that I know of to test your tests, no.
– Ullaakut
Aug 9 at 16:05
You don't write tests for your tests. Where does it end at that point if you do? Those tests for tests aren't covered. You'll need to write tests for your tests for your tests. But wait! Those tests for your tests for your tests don't have coverage so you better write tests for your tests for your tests for your tests.
By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.
I don't understand what this would measure. Do you have tests that cover your tests? And then tests for those tests? Is it turtles all the way down? Test coverage measures the code executed by the tests, not the code in the tests.
– Adrian
Aug 8 at 18:40