[
https://issues.apache.org/jira/browse/SUREFIRE-1860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana updated SUREFIRE-1860:
-----------------------------------
Description:
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.
was:
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.
* *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.
> extend ReportEntry interface and SimpleReportEntry with mandatory properties
> runMode:String, id:long, forkId:int
> ----------------------------------------------------------------------------------------------------------------
>
> 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.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
