3 ms·

> 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%

> 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 ;)