Doesn't run tests if they don't end with Test

I've hit this problem on pure JUnit4 tests as well.

I've hit this issue with only pure JUnit4 tests too. Our build machine is currently only running 27 of our 120+ tests (those with class names that begin or end in 'Test').

As I understand it, the only requirement for a JUnit4 test to be run is the presence of the @Test annotation on the test method. The name of the class and the (non)presence of @RunWith on the class should make no difference. The JUnit4 runner in Eclipse follows this behaviour, and correctly identifies all of our tests.

All this with JUnit4.4, and surefire 2.7-SNAPSHOT as at 20101119 (since I'd been hoping this had been fixed as part of SUREFIRE-482, but it doesn't seem that way).

Hmm... Having taken a very brief look at the code, it seems that surefire's JUnit4TestChecker.isValidJUnit4Test() method is doing the right thing. So it's just not getting the right list of test classes to apply that filtering to.

Following on from that, I've successfully worked around this issue by explicitly adding

<includes>
<include>*/.class</include>
</includes>

to my POM. I think this should be the default implicit behaviour - it makes no sense to filter by class name when the only requirement for inclusion is an @Test annotation.

I will be treating this as a documentation issue and update the FAQ wrt this issue, since it's already specified in the main documentation at http://maven.apache.org/plugins/maven-surefire-plugin/examples/inclusion-exclusion.html
. You have to update the include/exclude pattern to include all your classes if you want surefire to scan all your project classes for annotations. I will close this issue when the faq is updated.

Apologies, so it is. I missed that.

I would still argue that scanning all classes is a more useful default. JUnit imposes no restriction on test class naming, so it seems odd that surefire filters by name by default. Wouldn't a better default be to scan all classes, and let users impose their own restrictions if they're using a particular naming convention? It would avoid confusion and issues like this being raised, and I would have thought the performance hit is likely to be small on all but very large codebases.

Agree with Gareth's comment – this has caught us out in the past, too. I could provide a patch, unless there is a backwards-compatibility concern?

I have changed my mind too; and I think we'll try to fix this. But I think we'll probably take it together with any other changes to default values for "some future" release so we make one release that does all the modifications.

Nearly one year has been passed after the last comment. Are there any plans to implement this feature?

If not, the workaround above is ok. But it has to be:

<include>**/*.class</include>