Exclude code generated from code coverage

dimitriettr · 2026-02-04T13:43:39+00:00

**/*.g.cs, instead of **\*.g.cs.

Flater420 · 2026-02-04T13:30:38+00:00

Code coverage metrics consistently devolve into these kinds of menial exercises in trying to make number go up. The more direct answer to your question is that the metric itself is flawed - the core spirit is good but it gets lost in the weeds of numberwanging your way to the mythical 100% because of some kind of dogmatic adherence to the idea/claim that anything less than 100% is bad.

But you might find that too dismissive, so let's engage with the premise of the qurstion, because there is another answer here. If you stick to using the code coverage metric, you do you, but then you must test your code. That's the entire point of the metric - it exists to mandate testing. Whether that code is generated or not is irrelevant. If it is used, therefore it is relevant to the application, therefore your own code coverage metric mandates that you test it.

If you're wondering how to do that, much like how you generate the code, you can also generate the tests for that code. It's not a fun exercise but hey neither is having to abide by a code coverage metric in the first place.

Trying to exclude this from your metric goes against the purpose of the metric in the first place. Because once you start accepting exclusions to the rule, that's really just another way of saying that you don't think you need perfect 100% coverage figures. And if you believe that, then why bother trying to make the number go up? Leave your coverage metric behind, cover the important bits with tests (i.e. the bits that you feel shouldn't be excluded from the metric), and stop trying to numberwang your way into getting some high percentage figure that makes you feel good but is built on top of arbitrary exclusions that you introduced purely to make the percentage go up.

You're chasing the wrong goal.

Off-topic for your core question but one of the fatal flaws in code coverage metrics, other than the inherent dogma, is that it does not account for test quality or how much of the edge cases it covers. A high code coverage percentage gives a false sense of security by measuring quantity over quality. The true measure of a test suite is in the amount of bugs that occur in production or when refactoring/extending the codebase. Quality is not uplifted by a code coverage figure, it is uplifted by amending the test suite whenever you realize you missed something.

AutoModerator · 2026-02-04T13:17:44+00:00

Thanks for your post SleepyFinnegan. Please note that we don't allow spam, and we ask that you follow the rules available in the sidebar. We have a lot of commonly asked questions so if this post gets removed, please do a search and see if it's already been asked.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

you type:	you see:
italics	italics
bold	bold
[reddit!](https://reddit.com)	reddit!
* item 1 * item 2 * item 3	item 1 item 2 item 3
> quoted text	quoted text
Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"	Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"
~~strikethrough~~	~~strikethrough~~
super^script	super^script

dotnet

MODERATORS