[
https://issues.apache.org/jira/browse/SUREFIRE-1860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana closed SUREFIRE-1860.
----------------------------------
Resolution: Fixed
> 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
> * *testRunId:long*, which identifies the test run instead of the current ID
> represented by the combination of class+method.
> 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 {{testRunId: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 *run 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)
