Hi all,

Thanks to John Casey, the unwanted behavior of -Dtest=... with multiple surefire executions in one module is now fixed.
Now it will work as expected:  The test will run only in the execution where it runs in the whole batch.

Also note that besides SUREFIRE-806, Surefire 2.12 (which is now available in central) also fixes
SUREFIRE-803 - Multiple Failsafe executions - FAILURE in an execution prevents successive from running.
           We have been discussing this earlier.
SUREFIRE-809 - Implement boolean expression to define test group to be run.
           This is great improvement in possibilities of implementing large test suites in maven.
           I haven't found docs yet though.

Regards,
Ondra




-------- Přeposlaná zpráva --------
Od: John Casey (JIRA) <jira@codehaus.org>
Reply-to: John Casey (JIRA) <jira@codehaus.org>
Komu: zizka@seznam.cz
Předmět: [jira] (SUREFIRE-806) Make ignoring of <includes> and <excludes> on -Dtest=... optional (for multiple Surefire executions)
Datum: Wed, 18 Jan 2012 19:00:03 +0100 (CET)

[ https://jira.codehaus.org/browse/SUREFIRE-806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

John Casey closed SUREFIRE-806.
-------------------------------

       Resolution: Fixed
    Fix Version/s: 2.12

Created failIfNoSpecifiedTests parameter (-Dsurefire.failIfNoSpecifiedTests and -Dit.failIfNoSpecifiedTests when used from the CLI), which will determine whether test-execution blocks that don't contain one of the tests specified on the command line should fail the build or not. Default is to fail the build.

Also, in cases where there are multiple test execution blocks, to avoid running a specified test in the wrong block, the existing includes/excludes are now honored...the specified tests now act as a refining filter on these includes/excludes. This means that in cases where there are multiple test-execution blocks, you cannot run a test that wouldn't ordinarily be run by just using -Dtest=... any more.

In cases where there is only a single test-execution block, the specified tests should override the includes as before.

I also added three new integration tests to verify all of this behavior.
                
> Make ignoring of <includes> and <excludes> on -Dtest=... optional (for multiple Surefire executions)
> ----------------------------------------------------------------------------------------------------
>
>                 Key: SUREFIRE-806
>                 URL: https://jira.codehaus.org/browse/SUREFIRE-806
>             Project: Maven Surefire
>          Issue Type: Improvement
>          Components: Maven Surefire Plugin
>    Affects Versions: 2.11
>            Reporter: Ondrej Zizka
>            Assignee: John Casey
>             Fix For: 2.12
>
>         Attachments: surefire-806-testParam-hits-all-executions.zip
>
>
> Let's have a single module with multiple Surefire executions (e.g. with different Arquillian configs)
> Tests are divided to run in either one, using <includes> and <excludes>.
> Then, if you use -Dtest=..., the specified test(s) is run twice - once for each execution (and usually fails in one of them in our scenario).
> My suggestion is to introduce a Surefire config property which would make this behavior optional:
> {code}
> <configuration>
>   <ignoreIncludesOnSingleTest>false</ignoreIncludesOnSingleTest>
> </configuration>
> {code}
> This would cause Surefire to run the intersection of the two sets -
> one created by the mask from -Dtest=...,
> second created by the includes and excludes of the respective execution.
> Current description from http://maven.apache.org/plugins/maven-surefire-plugin/test-mojo.html :
> {quote}
> Specify this parameter to run individual tests by file name, overriding the includes/excludes parameters. Each pattern you specify here will be used to create an include pattern formatted like **/${test}.java, so you can just type "-Dtest=MyTest" to run a single test called "foo/MyTest.java".
> This parameter overrides the includes/excludes parameters, and the TestNG suiteXmlFiles parameter.
> {quote}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira