Stop Using Code Coverage

🌎 Find Me Here:

#Shorts

[tipeon]

If you reach 100% code coverage, the only thing that's guaranteed is that the PM will now demand 110% code coverage

[RoshanKumar-nxrk]

A high code coverage percentage does not guarantee high quality in the test coverage.
But a low code coverage number does guarantee that large areas of the product are going completely untested. In fact a lot of the value of code coverage data is to highlight not what’s covered, but what’s not covered.

[ardonjr]

THANK YOU! Man, I had to almost fight for this discussion at work. I had a teammate whose opinion was to always go for 100% code coverage. Man, we lost so much time for this nonsense. I hated working like that. 100% code coverage but still a non-functional app because it was slow as a snail and people didn't use it because it was too slow to use. 😅

[IAmSamuelCharpentier]

I mean if you can’t write a test that will touch done like or code, it means that line might not be necessary. Helped me remove clutter more than once

[Ziretech]

Code coverage THRESHOLDS are useless. Code coverage is a useful metric. Monitor code coverage, don't set thresholds! Also if you use TDD successfully, test coverage and quality tend to rise by itself...

[ajiteshmishra]

Can you explain how to protect our React Application and what securities we can implement.

This question is being asked in 2-3 years experience candidates.

Please answer

[StiekemeHenk]

I'm an advocate of TDD. I find it easy to find all possible code paths and write tests for them.
Then implementing the feature and seeing that indeed, my code is actually exactly what I designed is great and I can then get insights into various other metrics.
One of my favorite tests are mutation tests. Takes no effort and has shown me some surprising errors in my code.
(I went for 100% coverage in my software architecture analysis and design course 💀)

Also, line coverage is imo a bad metric. Branche coverage is a lot more useful and doesn't have the issue described.

[baka_baca]

Facts. I've gotten 100% code coverage before for lines & branches & functions, guess what, still had bugs. Tons of work to get that ideal number and it didn't solve the main problem I wanted to solve.

Don't focus on these kinds of metrics. They aren't always available for one, but they also are misguided at a fundamental level because no one except devs care about how something is written, they just care that it works. Test against the REQUIREMENTS you have for your software and don't worry as much about testing against the implementation.

[TheManOfTheHourEveryHour]

Code coverage sounds like a metric conjured up by novice PM stooges who've never written a single line of code 😂

[ANR]

Have 80% per change (pr) not necessarily for the whole app

[nocentii]

100% coverage is the ultimate target. Until you hit 100% line/branch coverage (and path, depending on whether your test suite accurately identifies paths), you haven't fully tested your software. If you were manually testing and you didn't test everything that your software should manage, then you aren't fully testing it, right? However, 100% coverage isn't always achievable within deadlines. Therefore, 80% is a tradeoff figure meant only for when time doesn't allow for achieving higher coverage - yet. If a team is *always* at 80% coverage, then either they're not being given the time to increase it, or they're not interested in doing so. A cultural issue, not a logistical one.

Writing tests shouldn't feel difficult. You're just setting up the conditions and giving instructions to do what you would otherwise do manually. i.e. You're coding.

If writing the tests is difficult, it's possible that it's not about you writing tests, but that you're writing a system that has low testability. This is where TDD comes in useful, as your system is written with testing in mind.

Above all, you can spend your career creating systems and fixing countless bugs that affect your and your users' livelihoods and reputation, or you can spend it creating systems that are verified to do exactly as much as they need to do, and are protected against the vast majority of bugs. If your clients don't want well-tested software, then consider whether you want to offer them poorly-tested software, or whether you demand a higher standard of your work and quality of life. If so, then the client must either go elsewhere, or they must accept the extra time and cost now to save spending it later, along with damage to their reputation due to the impact on their end users.

[suyashrahatekar]

I literally have 2 months of experience in my 1st ever project and I was asked to write unittest for python code. Even without any experience, I had a thought like how tf is such a bulshit metric is used in prod lmao. The focus should be on testing your core logic instead of 80% your total LoC.

[alisharobinson]

I disagree. If you are in a large monorepo project with many developers you already have test patterns in place. Whether you add or remove code it should not matter if you have patterns to follow. If you do not know how to test logic that is a big concern making it seem as though you do not know how it should function. Test coverage helps explain the why behind the logic making it easier to maintain for new devs. For small one off POC projects, yes it is not a huge concern, but for anything multiple devs are working on and planning to use long term it should have coverage eventually.

[bobthemagicmoose]

You need 100% coverage… but not necessarily in unit tests. Sometimes the granularity of unit testing is unnecessary. Also, sometimes the type system is enough of a check that unit testing each validation condition isn’t necessary.


That said, code coverage is objective and without it… people don’t write tests.

[PrzemysawSech]

Tests should cover sensible areas of an app. All non-crucial code should be consciously excluded from coverage. What's left should be covered in 100%.

Ideally, these 100% should cover the app's intention, not the implementation.

[insidyes]

Code coverage is the most useless thing

[Naej]

You need 100% code coverage in at least your domain

[brandon]

To be fair, you might get less bug reports if you actually covered uncovered code with tests. I don't know how you know which "tests effectively cover your code" without knowing what parts of your code need coverage. What are you using to measure effectiveness? Do you track how many bugs come from your "tests effectively [covering] your code"?

Quality shouldn't be reactive (i.e. during bug report time). It should be a proactive thing that code coverage can help you with.

"Hard" and "time-consuming" doesn't matter. Quality matters.

Lastly, if you TRULY feel like the line of code you added matters, then it should matter enough for you to cover it with a test. If not, remove it. That way, you'll undeniably have 100% code coverage.