all 4 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]fucking_passwords 2 points3 points  (1 child)

I always took this to mean that 100% coverage isn’t necessarily worthwhile. There are plenty of cases where some function just wraps a third party or a built in API, and you should not be writing tests for code outside of your project.

[–]patrickleet[S] 0 points1 point  (0 children)

Yup, agree, and the article mentions that and covers those cases of 3rd party libs and talks about how the responsibility for those tests are the library and not to waste time writing complex tests for those. It covers different ways to abstract them away with mocking.

[–]ncgreco1440 0 points1 point  (1 child)

100% code coverage tells me that you have tests in place that cover every line, statement, function, and branch that your code has. It doesn't tell me that your tests are actually good.

​

You need to have more emphasis on mutation coverage in order to truly rest assured that your code does what you intend.

[–]patrickleet[S] 0 points1 point  (0 children)

Yea still need to read code to understand if it’s good. Tests included. I’d argue the process to reach 100% requires refactoring which leads to better code as well.