[
https://issues.apache.org/jira/browse/SUREFIRE-1860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana updated SUREFIRE-1860:
-----------------------------------
Summary: extend ReportEntry interface and SimpleReportEntry with mandatory
properties runMode:String, testRunId:long (was: extend ReportEntry interface
and SimpleReportEntry with mandatory properties runMode:String, id:long,
forkId:int)
> extend ReportEntry interface and SimpleReportEntry with mandatory properties
> runMode:String, testRunId:long
> -----------------------------------------------------------------------------------------------------------
>
> Key: SUREFIRE-1860
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1860
> Project: Maven Surefire
> Issue Type: New Feature
> Components: JUnit 3.x support, Junit 4.7+ (parallel) support, Junit
> 4.x support, JUnit 5.x support, Maven Failsafe Plugin, Maven Surefire Plugin,
> TestNG support
> Reporter: Tibor Digana
> Assignee: Tibor Digana
> Priority: Major
> Fix For: 3.0.0-M6
>
>
> 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.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
