4 ms·

Quite possibly. I will assert, though, from my experience, and the wisdom I've garnered from talking to people around unit testing, that as code assypmtotically

Quite possibly. I will assert, though, from my experience, and the wisdom I've garnered from talking to people around unit testing, that as code assypmtotically approach 100% code coverage, the complexity of said code will tend to go up exponetially (or worse). I don't have significant proof other than to say that things like DI and IoC start to get used in places that make little sense, which means complexity that wouldn't exist without tests. I also have anecdotes of defensive code I've written, with code branches that 'will never execute'. Branches that are there in case I missed something subtle, that simply log an error, or otherwise throw some exception. I can verify the code works before walling it off, but if you ask me to unit test those lines of code, now I need ways to set the internals of a function externally, or otherwise add code to allow variables to be set in a way that shouldn't be possible. This leads to complexity. And if you asked me to test it, I'd just quietly delete the defensive code rather than poison internal state variables.

josteink 9y ago
> as code assypmtotically approach 100% code coverage, the complexity of said code will tend to go up exponetially (or worse). I think attempting to reach 100% coverage is a good direction to steer against while you have low coverage, but not worth it as a an ultimate goal. As you get closer (even as as TDD-proponent), I'm pretty sure the costs outweighs the gains, and you get problems like the ones you describe here. Where a "reasonable" cutoff point may be... Now that's a harder discussion :)
- bonesss 9y ago
  > Where a "reasonable" cutoff point may be... Now that's a harder discussion :) I think this is something that should really be reflected in your systems overriding architecture... A 100% tested persistent ignorant Domain library is A Good Thing. But your Infrastructure library, or your build scripts, or things that only really make sense as integration tests? Only as much as makes sense. While it's an individual heuristic: if I can see myself arguing for more than 30 minutes why it's meaningless to test something then I have no problem letting it slide ;)

josteink 9y ago

> as code assypmtotically approach 100% code coverage, the complexity of said code will tend to go up exponetially (or worse). I think attempting to reach 100% coverage is a good direction to steer against while you have low coverage, but not worth it as a an ultimate goal. As you get closer (even as as TDD-proponent), I'm pretty sure the costs outweighs the gains, and you get problems like the ones you describe here. Where a "reasonable" cutoff point may be... Now that's a harder discussion :)

bonesss 9y ago
> Where a "reasonable" cutoff point may be... Now that's a harder discussion :) I think this is something that should really be reflected in your systems overriding architecture... A 100% tested persistent ignorant Domain library is A Good Thing. But your Infrastructure library, or your build scripts, or things that only really make sense as integration tests? Only as much as makes sense. While it's an individual heuristic: if I can see myself arguing for more than 30 minutes why it's meaningless to test something then I have no problem letting it slide ;)