You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@deltaspike.apache.org by "Gerhard Petracek (JIRA)" <ji...@apache.org> on 2014/11/01 20:31:33 UTC

[jira] [Updated] (DELTASPIKE-727) CdiTestSuiteRunner.LogRunListener logs multiple times

     [ https://issues.apache.org/jira/browse/DELTASPIKE-727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Gerhard Petracek updated DELTASPIKE-727:
----------------------------------------
    Fix Version/s:     (was: 1.1.0)
                   1.1.1

> CdiTestSuiteRunner.LogRunListener logs multiple times
> -----------------------------------------------------
>
>                 Key: DELTASPIKE-727
>                 URL: https://issues.apache.org/jira/browse/DELTASPIKE-727
>             Project: DeltaSpike
>          Issue Type: Bug
>          Components: TestControl
>    Affects Versions: 1.0.2
>         Environment: DeltaSpike 1.0.2 and master
> OpenWebBeans 1.2.6
> JUnit 4.11 via maven-surefire-plugin 2.17
>            Reporter: Ronald Steininger
>            Priority: Trivial
>             Fix For: 1.1.1
>
>
> CdiTestRunner logs the "started", "finished" and "failed"-events via org.apache.deltaspike.testcontrol.api.junit.CdiTestSuiteRunner.LogRunListener. Using CdiTestRunner in more than one test class leads to the repeated logging of said lines, with one more duplicate per @RunWith(CdiTestRunner) usage.
> I've analyzed the problem a bit: CdiTestRunner works by adding an LogRunListener instance to the RunNotifier in CdiTestRunner#addLogRunListener, which also keeps track of the RunNotifiers that already have the Listener attached via the static notifierIdentities Set, only adding the Listener if the RunNotifier isn't in the Set. The problem is that notifierIdentities gets cleared in CdiTestRunner.AfterClassStatement#evaluate, which leaves the Listener alone and thus defeats the purpose of the Set in the first place.
> I've tried removing the notifierIdentities.clear() from evaluate which fixes this issue, but I'm unsure if that's the right fix for the problem. (Writing a unit test which demonstrates the issue would be easy, but I have no idea how to provide a test that actually fails based on the test's log output.)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)