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/a1bdb98c-385a-45eb-afce-c689c3a9d339%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to