Since constructors was actually executed, JaCoCo as any other coverage tools shows them as executed. Don't know why you want to overcome this, but as a way to do this - you can reset the data collected by JaCoCo before execution of test via http://www.jacoco.org/jacoco/trunk/doc/api/org/jacoco/agent/rt/IAgent.html#getExecutionData(boolean) obtained via http://www.jacoco.org/jacoco/trunk/doc/api/org/jacoco/agent/rt/RT.html#getAgent() . This will probably require explicit saving of data at the end of test(s) via http://www.jacoco.org/jacoco/trunk/doc/api/org/jacoco/agent/rt/IAgent.html#dump(boolean) so that it won't be lost when next test-suite resets the data. Since this creates dependency from tests on coverage library, be careful to protect all this from a situation when tests executed without coverage library, e.g. by doing this from custom pluggable JUnit Listener.
On Monday, June 12, 2017 at 12:34:41 AM UTC+2, Koen De Groote wrote: > > I have looked at the documentation and found nothing that sounds like > this, so I came here. > > I have some unit tests that work by first populating an in-memory > database, using objects I create during the `@Before` part of the unit test. > > The downside is that JaCoCo's reports are showing that the code in the > constructor for those classes has been traversed, while actually the test > itself, which happens after the database population, didn't access that > code. > > So, is there a way to overcome this with only JaCoCo or shall I have to do > something else to avoid this issue? > -- You received this message because you are subscribed to the Google Groups "JaCoCo and EclEmma Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jacoco/996ac31d-22dd-4520-923a-8083566f105b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
