Hi Michael,
Is it now possible get the "probe-flow" out of jacoco
No, probes are simple boolean flags.
If not, do you think it fits into concept?
The instrumentation techniques used by JaCoCo could also be used for a
more complex runtime which records every probe execution in its
sequence. This will add significant runtime overhead, that's why this is
not in scope of the JaCoCo project.
Regards,
-marc
On 2017-11-24 09:43, [email protected] wrote:
Am Donnerstag, 21. September 2017 17:38:22 UTC+2 schrieb Marc R.
Hoffmann:
Hi Jakub,
We can get this data from actual stack trace when code was visited in
a coverage counters spots (places analyzed by JaCoCo). An extension of
the ClassProbeAdapter and changes in org.jacoco.core.internal are
needed.
I don't think this is the correct place: ClassProbeAdapter is used at
the time of instrumentation or analysis. It is not invoked at
execution time (only indirectly when using on-the-fly-instrumentation
and classes are loaded the first time).
Execution is recorded by bytecode probes inserted by the
instrumentation process, please
see http://www.jacoco.org/jacoco/trunk/doc/flow.html
Regards,
-marc
On 2017-09-21 14:22, [email protected] wrote:
Hello Marc,
Here is my description of the approach.
Add the option to choose a mode of JaCoCo run. This option could be
handled by a system property named e.g.
org.jacoco.source.detection.enabled with possible values true or false
configured in the maven pom file. Default value should be false and
JaCoCo execution will be the same as before.
Identify test calling source code.
We can get this data from actual stack trace when code was visited in
a coverage counters spots (places analyzed by JaCoCo). An extension of
the ClassProbeAdapter and changes in org.jacoco.core.internal are
needed.
Verify new functionality for all analytical methods.
Data storing
Implementation of storing extension in package org.jacoco.data.core.
We need to store data about from where was code called. Saving should
be fast and duplicities of calls should be ignored.
Display data
Extend actual report with data about source calling (changes in
org.jacoco.report package),
Data merge - in the jacoco report we can see coverage from package to
code. For a package it would be nice to display all tests. So I would
like to show what tests cover each particular package.
Best regards
Jakub
--
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/77d84d54-62ef-45df-94d1-ffff057f033c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Hi Marc, hi Jakub,
recently I started my work on a tool to find dublicate tests in a
large test base. Base idea is to collect execution pathes of all tests
through the system under test. Then in an anlysis phase execution
pathes are compared and dublicates determined (mostly just like Marc
wrote above).
The problem with this: To find dublicates it's not enough to know
which probes have been traversed at all, but you need to know exactly
the exact flow through the probes, i.e. a test doing first A then B is
some different than doing first B then A. A test doing 1 time A is
something different than a test doing 2 times A and so on.
My question: Is it now possible get the "probe-flow" out of jacoco. If
not, do you think it fits into concept?
Regards,
Michael
--
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/59bf612478f069427d3d327b9cbc8fae%40mountainminds.com.
For more options, visit https://groups.google.com/d/optout.
