Code Coverage Integration
Reported by benrady (at gmail) | October 13th, 2009 @ 05:37 PM
from Daniel Yukio Yokomizo:
Is it in the plans or there's a way to integrate Infinitest with code coverage tools? Currently I'm using EclEmma to assess coverage inside Eclipse and thought it would be a good idea to have this information as Infinitest runs the tests, for example if I change some code and the tests succeed but coverage is worse it would be nice to have a warning on the new, uncovered, line.
from Ben Rady:
Oh, we've got plans...it's the implementation that eludes us
:-)
The one tricky bit is that because Infinitest is selectively running tests, it can't really tell you what code is uncovered. It can definitively tell you that a particular change covered a specific set of lines, or statements, but in terms of your overall coverage for the entire test suite, we can't really tell you that a line is "uncovered". Is this actually a problem? I have no idea.
from Daniel Yukio Yokomizo:
Can't Infinitest establish a baseline at some point (e.g. when a
explicit build is invoked or implicitly like clean+build
automatically )? Just a thought.
from Ben Rady:
Also, how you represent this information is very important. I think
the red/green line highlighting that you see in most coverage tools
is awful. Makes my eyes bleed every time I look at the screen. One
thing I've thought about is a subtle hint in the editor that lets
you know a particular statement is covered. Turning the semicolon
green, perhaps.
from Daniel Yukio Yokomizo:
I was thinking about a warning on lines that are new and uncovered.
If a line is new or was changed and it wasn't covered by the test a
warning is placed on the line. Other lines should be ignored. If I
later write a new TestCase that covers the line marked with the
uncovered warning, it should be cleared. AFAICS this will never
show false positives (i.e. lines that are covered but show as
uncovered) but it may cause false negatives (i.e. uncovered lines
without warnings). As usual the user can always invoke a full build
(forcing all tests to run), so the complete coverage would be
assessed. IMHO Infinitest works best when I can immediately see if
I introduced a bug in the program (essentially I care about what I
just did not about the rest of the program), so a coverage feature
that shows only if my last change is uncovered is enough (for
me).
Comments and changes to this ticket
-
Sebastian Vilstrup November 30th, 2009 @ 01:30 PM
- Assigned user set to benrady (at gmail)
I have an idea for the presentation:
How about.. showing uncovered code as a compiler warning, just like you show test failures as compiler errors?
Please Sign in or create a free account to add a new ticket.
With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.
Create your profile
Help contribute to this project by taking a few moments to create your personal profile. Create your profile ยป
Continuous Test Runner for Java