How to compare ExecutionDataStore

[drek...@gmail.com]

I'm writing some code that processes exec data (another variant on per-test metrics). The next task is to compare session instances for equivalence. ExecutionData and ExecutionDataStore are final classes without hashcode, equals or compare methods. They are difficult to treat as entities in their own right instead of anonymous midpoints along the way to a CoverageBuilder/Analyzer (which, by the way, uses those final types and not an interface!).

My first attempt to build a RoaringBitmap relied on the order of ExecutionData instances provided by EDS#accept(visitor). Seems EDS has-a HashMap so is entirely unreliable wrt order and I'm currently weighing up creating my own EDS.

Have I missed some utility method?

[Marc Hoffmann]

Hi,

ExecutionData is plain data holder. Implementing equals/hashcode semantik is always specific to the use case (is it the id? is it more data?). Therefore it doesn’t make sense to hardcode a specific semantic into our API.

I recommend using an external Comparator that implements your specific requirements.

Regards,

-marc

--
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 jacoco+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jacoco/64e1b024-f6bb-4bb0-ba8c-ebaa46f8e8d5%40googlegroups.com.

[drek...@gmail.com]

Ok, this is what I'm planning but I have to repeat some stuff and check certain understandings. A file has multiple Sessions, a Session has multiple ExecutionData, an ExecutionData has probes for one Class.

Q: Is the order of ExecutionData blocks from the file deterministic in any way? (name, id, encounter-order in the test session etc). I'm going to assume not.

Q: Within a Session, can the same Class appear more than once?

I would posit that the principle-of-least-surprise is that ExecutionData is equal based on its own assertCompatibility() method; Probe count is included but not probe content. This _is_ a single usecase I agree but it's also the de facto expectation - equal on the "key" not the "content"

[Marc Hoffmann]

Q: Is the order of ExecutionData blocks from the file deterministic in any way? (name, id, encounter-order in the test session etc). I'm going to assume not.

A: Not at all. The agent dumps the classes for data in an arbitrary sequence

Q: Within a Session, can the same Class appear more than once?

A. No, the agent dumps each class once

I would posit that the principle-of-least-surprise is that ExecutionData is equal based on its own assertCompatibility() method; Probe count is included but not probe content. This _is_ a single usecase I agree but it's also the de facto expectation - equal on the "key" not the "content"

I agree. But ExecutionData is not intended to be used as a key. So to me applying the principle-of-least-surprise is no equals/hashcode methods ;)

Regards,

-marc

 

--
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 jacoco+un...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jacoco/2ee2bd73-fa17-4f43-94d5-ef95ab40a0c9%40googlegroups.com.

[drek...@gmail.com]

A follow up question. I'm comparing Sessions to identify duplicates using the raw ExecutionData#probes (after all a dupe isn't defined by having the same % coverage)

The ExecutionData, and therefore the comparison, still includes the test code which I would like to filter out by reusing Jacoco's logic. I've started looking through Analyzer but it gets deep pretty quick and clearly isn't intended for the casual API user to grok.

Can you provide any tips on on where I can hook into the first level of Analyzer logic (where it filters execution-class-ids by classes discovered) without the rest of the ASM + ICounter stuff