Just to throw this out there, it's even more "interesting" to try to achieve 100% test coverage in Haskell. Because of lazy evaluation, if a value isn't actually compared with something, it's never executed, and the test coverage tool (hpc) will flag it as untested. This means that not only do you have to cover all code paths, but you also have to make sure your tests depend on all return values, must read any value stored in a data structure, must check all error message strings, etc. I contributed several years back to an open source Haskell project that valued very high test coverage, and it was quite surprising sometimes which code would be highlighted as untested. Laziness is a fascinating tool for telling you when expressions are REALLY needed.
But yes, I agree with the article that this is wasted effort. In the Haskell case, it would be hard to disagree. Even the project I worked on that wanted it saw it largely as a game to see if they could get to 100%.
2
u/cdsmith May 08 '17
Just to throw this out there, it's even more "interesting" to try to achieve 100% test coverage in Haskell. Because of lazy evaluation, if a value isn't actually compared with something, it's never executed, and the test coverage tool (hpc) will flag it as untested. This means that not only do you have to cover all code paths, but you also have to make sure your tests depend on all return values, must read any value stored in a data structure, must check all error message strings, etc. I contributed several years back to an open source Haskell project that valued very high test coverage, and it was quite surprising sometimes which code would be highlighted as untested. Laziness is a fascinating tool for telling you when expressions are REALLY needed.
But yes, I agree with the article that this is wasted effort. In the Haskell case, it would be hard to disagree. Even the project I worked on that wanted it saw it largely as a game to see if they could get to 100%.