« Return back, not out | Main | The Fertile Middle-Ground Between Static and Dynamic Typing »

December 14, 2010

Comments

Cees de Groot

I've thought about this more than once, but somehow it never seems to reach the top of my to-do list. For my line of work, this would actually be simple - we run a big website, so any piece of code is running on multiple servers anyway. Just add a coverage server, put it on low weight in the load balancer, and wait for the data to come out...

Overhead and cost would be minimal, benefits would be big - especially when you'd compare coverage from integration/acceptance tests (typically high maintenance) to production coverage. What does it say if these tests show coverage on code that never gets triggered in production? ;-)

Martin Probst

This depends a lot on which tool you use, but for example the EMMA coverage tool for Java provides excellent results at a cost of some 20% runtime overhead, which might very well be acceptable on your production system (at least part of the time).

http://emma.sourceforge.net/

Daniel Wurst

Do you think of something like the Usage Data Collector for Eclipse (http://www.eclipse.org/epp/usagedata/) or really on a fine granular code level.

Marick

20% overhead for coverage seems high. In C, you can get branch coverage by rewriting

if (f()) ...

as

if (temp = f(), Big_array[Branch_number + temp], temp) ...

... which I believe comes out as much less than 20% on average C code (but it's been > 20 years, so I don't remember the numbers).

Llewellyn falco

Resharper has the feature of turning dead code grey. I'm surprised at how much code ends up being grey. But it's always easy to delete which is my first step: remove clutter

Heikki Naski

Most of the time, I wouldn't say the greatest obstacle is performance. Granted, you need to save the data somewhere but there are a lot of tricks you can do to make it faster. The main problem I'd think is in addition to the initial construction work, all the optimization will require development time and further maintenance. A reason for this not being a common practice might be the management not understanding the benefits, which in itself might be a problem with the development team not being able to properly communicate them.

Jon Jagger

Why not integrate into your editor!? Imagine an IDE that shows you not just the line number for each line of code, but also its live coverage count !

The comments to this entry are closed.