Hi Leo, First of all - there is extensive documentation covering features of EclEmma ( http://www.eclemma.org/ ) and its underlying coverage engine JaCoCo ( http://www.jacoco.org/jacoco/ ). Please study.
In particular there is documentation about APIs that JaCoCo exposes - http://www.jacoco.org/jacoco/trunk/doc/api/index.html The interesting part is "JaCoCo Runtime" package "org.jacoco.agent.rt" with description "API to access the JaCoCo agent from within the JVM under test", which contains class http://www.jacoco.org/jacoco/trunk/doc/api/org/jacoco/agent/rt/RT.html - "Entry point to access the JaCoCo agent runtime." that provides access to http://www.jacoco.org/jacoco/trunk/doc/api/org/jacoco/agent/rt/IAgent.html - "Runtime API and MBean agent interface." In a usual Java application this can be easily used via reflection, because agent is loaded into application classloader and so application can easily access these classes. For example to call method "reset" which will clear already collected information: public class Example { public static void main(String[] args) throws Exception { Object jacocoAgent = Example.class.getClassLoader().loadClass("org.jacoco.agent.rt.RT").getMethod("getAgent").invoke(null); jacocoAgent.getClass().getMethod("reset").invoke(jacocoAgent); } } But I assume that your tests are executed inside OSGi container? In this case access gets complicated. Fortunately the exact same API can be exposed via MBean by setting agent option "jmx=true" - see http://www.jacoco.org/jacoco/trunk/doc/agent.html However EclEmma exposes limited set of agent options and "jmx" is not one of them - see http://www.eclemma.org/userdoc/preferences.html Luckily there is no validation of properties, so you can abuse a bit e.g. "includes" to set "jmx=true" : <https://lh3.googleusercontent.com/-NHL9sp856Ww/WqwptnQxDgI/AAAAAAAAB9Y/X68iWP07eAwtfugCNEhsO5hfit8QopyCgCLcBGAs/s1600/EclEmma%2B-%2BPreferences.png> but please don't tell anyone that I recommended to do this ;) :D we state on the same page: "Use these options with caution! Invalid entries might break the code coverage launcher." For the example - below is screenshot of usage of EclEmma for the one of its own UI tests that use SWTBot and are executed inside OSGi container, pay attention on elements marked as covered: <https://lh3.googleusercontent.com/-44-biwWyWQU/WqwrsBKvF8I/AAAAAAAAB9k/MsiK1A8_rVYNvDM0R1KNAxMLCz6ITdfxQCLcBGAs/s1600/1.png> Now let's add reset via MBean and execute this test again: <https://lh3.googleusercontent.com/-o2CNCMedTc4/WqwrvhqLfLI/AAAAAAAAB9o/wJTGWdt-ZU4jfXbtcCwtiHy4tW7UsE16wCLcBGAs/s1600/2.png> As you can see from screenshots: code above "reset" is not considered as covered anymore, as well as creation of "view" that is done by this code, but disposal of "view" is considered as covered because executes after "reset". Hope this helps. P.S. please take a bit of time to study documentation. Regards, Evgeny On Wednesday, March 14, 2018 at 3:32:49 PM UTC+1, [email protected] wrote: > > Hello, > > While debugging SWT, I have the situation where I'm interested in what > happens during a particular event (e.g low level drawing issues). > > Currently I do a Thread...sleep(..) manually dump the execution. Let the > event run and at the end I do System.exit(..). > This gives me a picture of what ran during that event. > > However, above method is sometimes hard to use with some events. (e.g Drag > and Drop debugging). > > Is there any way to programatically initiate a "Dump Execution Data" ? > (with "reset data" enabled). > > Thank you > > -- 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/4f49caf2-7403-4b76-a0b9-e2f86195c042%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
