[jira] [Created] (SUREFIRE-2213) @Categories (JUnit4) are handeld differnt than JUnit's built-in Categories-Runner

["Christian Nüssgens (Jira)" <ji...@apache.org>]

Christian Nüssgens created SUREFIRE-2213:
--------------------------------------------

             Summary: @Categories (JUnit4) are handeld differnt than JUnit's built-in Categories-Runner
                 Key: SUREFIRE-2213
                 URL: https://issues.apache.org/jira/browse/SUREFIRE-2213
             Project: Maven Surefire
          Issue Type: Bug
          Components: Junit 4.x support, Maven Surefire Plugin
    Affects Versions: 3.2.2, 3.2.1, 3.1.2, 3.1.0, 3.0.0, 3.0.0-M9, 3.0.0-M8, 3.0.0-M7, 3.0.0-M6, 3.0.0-M5
            Reporter: Christian Nüssgens


With SUREFIRE-1695 a change was introduced which modified the behavior how {{<groups/>}} and {{<excludeGroups/>}} are handled.


Assume the following Test Classes
{code:java}
@Category(CategoryA.class)
public abstract class AbstractTest {
}

public class TestA extends AbstractTest {
    @Test
    public void testIt() throws Exception {
        //do test
    }
}

@Category(CategoryPlayground.class)
public class PlaygroundTestA extends TestA {

    @Test
    public void testIt() throws Exception {
        // do nasty stuff like while(true)
    }
}
{code}

The built-in categories Runner behaves as follows
{code:java}
@RunWith(Categories.class)
@IncludeCategory({CategoryA.class})
@SuiteClasses({TestA.class, PlaygroundTestA.class})
public class TheSuite {
}
{code}

If run: only {{TestA}} is executed. The "closest" Categories declaration wins, although the Categories-annotation itself is "inheritable".

Surefire does behave differently:
{code:xml}
<!-- .... -->
<configuration>
              <groups>CategoryA</groups>
</configuration>
<!-- .... -->
{code}
If run ({{mvn test}}) surefire will execute {{TestA}} and {{PlaygroundTestA}} (since surefire 3.0.0-M5)

We were quite surprised that this behavior changed from surefire 2.x to 3.x and is now not reflecting the way it is implemented in JUnit itself.

I'm currently not sure _who_ is already relying on the _new_ behavior. 
Is it possible to restore the "old" behavior? Or would it be a convenient approach to make it?configurable. 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)