We are missing two properties in the ReportEntry interface
- runMode:RunMode, which "informs" the reporters that the statistics data is for normal tests or re-run tests
- id:long, which identifies the test run instead of the current ID represented by the combination of class+method.
Additional forkId used in the class ForkStarter and ForkClient, and NULL in the in-plugin implementation.
- forkId:long, which identifies the id of the sub-process (forked JVM)
Currently the XML reporter is stateful and the run mode is determined by the timing and the order of normal tests and rerun tests. The problem is when we run the tests in parallel. After we would employ the id:long we would not have these problems and we would solve much more like JUnit5's Dynamic tests and the ability to run Cucumber scripts.
The reporters should identify the test run by the combination of forkId + test id. The forks have no notion about the other forks, and it's even more difficult to make the test ids coherent (without duplicates) across the forks because they are very dynamically created and finished during the lifetime of the plugin execution. Therefore the reporter implementation should respect the forkId too.
Currently the JUnit47 provider has a cache, TestMethod, which has the console logs in memory and sends these after the class has finished. This is memory resources problem. We are aiming for sending these logs immediately, and have the implementation stateless.