The myth of code coverage
-
1/3 of the code every software project is irrelevant, buggy, overly complicated, or simply sucks
2 out of 3 lines of code approve of this message
-
1/3 of the code every software project is irrelevant, buggy, overly complicated, or simply sucks
2 out of 3 lines of code approve of this message
I don't understand the logic here; a third of code in a given solution is poor, so don't test it. Instead, test the "good" code. (And how does he know which is which? Apparently magic.)
-
1/3 of the code every software project is irrelevant, buggy, overly complicated, or simply sucks
2 out of 3 lines of code approve of this message
Ironically, I completely disagree with his recommendations. It is actually the crappy code and the frequently changing code that requires the most code coverage! That is certainly how I base my unit and integration tests - what's changing the most, and what is so fragile and poorly documented and understood. Because when I get around to refactoring shitty code, I want test to verify that I haven't broken something!
Latest Articles:
Thread Safe Quantized Temporal Frame Ring Buffer -
Ironically, I completely disagree with his recommendations. It is actually the crappy code and the frequently changing code that requires the most code coverage! That is certainly how I base my unit and integration tests - what's changing the most, and what is so fragile and poorly documented and understood. Because when I get around to refactoring shitty code, I want test to verify that I haven't broken something!
Latest Articles:
Thread Safe Quantized Temporal Frame Ring BufferMy thoughts exactly! Besides, it's not even about percentages, but about writing effective tests. I've literally seen some untestable code that had a high coverage. The code couldn't be tested because it relied on some settings that could only be set in production (HttpContext or some such) and couldn't be mocked (well, it could, if better developers had written it). Every test simply checked if the code throwed the expected NullReferenceException :laugh: But they could tell their customers they had a high test coverage :sigh:
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
Ironically, I completely disagree with his recommendations. It is actually the crappy code and the frequently changing code that requires the most code coverage! That is certainly how I base my unit and integration tests - what's changing the most, and what is so fragile and poorly documented and understood. Because when I get around to refactoring shitty code, I want test to verify that I haven't broken something!
Latest Articles:
Thread Safe Quantized Temporal Frame Ring BufferMy thoughts exactly. I would rather have higher test coverage around the poorly written code that is more likely to break somewhere.
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare Home | LinkedIn | Google+ | Twitter
