ECLEmma *sometimes* stops showing coverage (green) for *some* classes

[r...@corfield.f9.co.uk]

Hi

I have recently started using ECLEmma with Eclipse to analyse out test code coverage.

I have to say that it's excellent & has made a big difference to us.

However ... sometimes I get in the situation with certain classes that the highlighting is always red when running Coverage As => JUnit Test. Now I know there is coverage of this class because it's showing as such in sonar, which runs independently. Also I can get green highlighting for a class in the same package, so it's not a general failure.

In the past I've resolved this kind of problem by restarting Eclipse, however I now have a class that's resisted displaying coverage despite Project Clean, Maven Update, Maven clean/install, Restart Eclipse etc.

Can anyone give me any hints as to what might be causing this behaviour & how I might go about debugging the cause for this. Does ECLEmma write to a log file, for example?

Many thanks

Richard

[r...@corfield.f9.co.uk]

I have followed the advice given in post number 9 in the following link & started eclipse in a console debug mode:
http://sourceforge.net/projects/eclemma/forums/forum/614870/topic/5113208

The output is quite interesting. I ran three test classes. The first one, which only shows red, has a negative number for the number of bytes loaded. Whereas the second two classes do not include a negative sign. I wonder if this is relevant?

Debug options:
file:/C:/eclipse/eclipse/.options loaded
Time to load bundles: 9
Starting application: 1470
osgi> Application Started: 22311
[performance] 1,841 ms for loading EntryManagerImplTest (22-Jan-2013 14:41:37)
[performance] -112,477,024 bytes for loading EntryManagerImplTest (22-Jan-2013 1
4:41:37)
[performance] 246 ms for loading ElementManagerImplTest (22-Jan-2013 14:43:15)
[performance] 49,204,136 bytes for loading ElementManagerImplTest (22-Jan-2013 1
4:43:15)
[performance] 202 ms for loading BookmarkManagerTest (22-Jan-2013 14:43:50)
[performance] 45,891,320 bytes for loading BookmarkManagerTest (22-Jan-2013 14:4
3:50)

Thanks

Richard

[Marc Hoffmann]

Hi Richard,

the numbers simply compare used heap before and after analysis. This
values can be blured by garbage collection and other jobs. In general
these figure only make sense for analysis of *large* Java projects.

You can check something else: After running your test with coverage
select the option "Open Execution Data" from the context menu of the
coverage view. This will open an editor listing all classes where probes
have been collected for. Can you please look for your class and see
whether probes have been executed?

Thanks,
-marc

[r...@corfield.f9.co.uk]

Ok, that's interesting. Thank you.

I've had a look at the Execution Data and for the class under test that's all red I have total probes: 1542, Executed probes: 476.

For a similar class which is rendering some green for coverage OK, I have total probes: 157, Executed probes: 32.

This seems to imply that the probes have been executed properly, but that the problem is with the rendering of the highlighting in the UI at the end of the process?

Thanks

Richard

[Marc R. Hoffmann]

This looks like a different version of the class is used at runtime.
This typically happens when you use e.g. mocking frameworks which modify
the classes under test ("spy") or other frameworks that do bytecode
tranformation.

Cheers,
-marc

[r...@corfield.f9.co.uk]

Yes, this is the answer.

I had not noticed previously that a colleague had used a spy() on the class under test in one of the test methods. Without that spy() being run the code coverage shows green again.

Many thanks!

Richard