Comments on: Code Coverage as a Metric http://laribee.com/blog/2007/02/28/code-coverage-as-a-metric/ Coaching, Process, Design, Speculation Sat, 22 Nov 2008 07:14:26 +0000 http://wordpress.org/?v=2.6.3 By: the ‘bee log / Using Attributes to Exclude Code from Coverage http://laribee.com/blog/2007/02/28/code-coverage-as-a-metric/#comment-4574 the ‘bee log / Using Attributes to Exclude Code from Coverage Wed, 18 Apr 2007 14:07:53 +0000 http://laribee.com/blog/2007/02/28/code-coverage-as-a-metric/#comment-4574 [...] got pretty good coverage (despite my mixed feelings on the code coverage metric) on the library but, still, there’s this one class with nothing but HttpContext this and [...] [...] got pretty good coverage (despite my mixed feelings on the code coverage metric) on the library but, still, there’s this one class with nothing but HttpContext this and [...]

]]> By: Dave http://laribee.com/blog/2007/02/28/code-coverage-as-a-metric/#comment-925 Dave Sun, 04 Mar 2007 23:42:07 +0000 http://laribee.com/blog/2007/02/28/code-coverage-as-a-metric/#comment-925 Yeah, I'm with you. I'm not saying one should run without or ignore the metric and agree whole heartedly that it is a "decent indicator", but I do think that the number tells you almost absolutely nothing of the quality of the coverage. Let's say a lot of your coverage comes from stuffing/fetching values from simple, pass-through mutators/accessors. What do those points rolling up into the percentage tell you then? Even with 100% coverage (through proper exclusion) there's no guarantee that the tests are any good or represent a reasonable set of assertions. All I'm saying is: getting to the top of the code quality hierarchy of needs comes down to difficult-to-measure things and human factors such as testing skill, pair programming, code review, etc. Once the people get there I'm curious to see if the metric expressed as a delta (iteration over iteration or day over day) might not be another good thing for our bag of tricks. Yeah, I’m with you.

I’m not saying one should run without or ignore the metric and agree whole heartedly that it is a “decent indicator”, but I do think that the number tells you almost absolutely nothing of the quality of the coverage.

Let’s say a lot of your coverage comes from stuffing/fetching values from simple, pass-through mutators/accessors. What do those points rolling up into the percentage tell you then? Even with 100% coverage (through proper exclusion) there’s no guarantee that the tests are any good or represent a reasonable set of assertions.

All I’m saying is: getting to the top of the code quality hierarchy of needs comes down to difficult-to-measure things and human factors such as testing skill, pair programming, code review, etc. Once the people get there I’m curious to see if the metric expressed as a delta (iteration over iteration or day over day) might not be another good thing for our bag of tricks.

]]> By: chris donnan http://laribee.com/blog/2007/02/28/code-coverage-as-a-metric/#comment-904 chris donnan Sun, 04 Mar 2007 16:10:55 +0000 http://laribee.com/blog/2007/02/28/code-coverage-as-a-metric/#comment-904 Code Coverage is a useful thermometer. It is not the actual 'health' per-say - but a decent aggregate indicator of health. In a nutshell - if you have 0% coverage - you are dead. If you have coverage of something - your are better than dead. If you - in general have coverage in a good area (say 70%) then you are probably doing something alright. Code Coverage is a useful thermometer. It is not the actual ‘health’ per-say - but a decent aggregate indicator of health. In a nutshell - if you have 0% coverage - you are dead. If you have coverage of something - your are better than dead. If you - in general have coverage in a good area (say 70%) then you are probably doing something alright.

]]>