I was able to get this to work by modifying the sure-fire plugin source. I updated AbstractDirectoryTestSuite.collectTests() to be protected. And I over-rode that method in JUnit4DirectoryTestSuite to list all the jars from the class path and search for unit tests within them adding the discovered unit tests to the list of collected tests. It does seem to work.
I guess, if SurefirePlugin, exposed the name of junit4DirectoryTestSuite as a parameter, like it exposes the testNG and junit artifact names. I would have been able to accomplish this without needing any changes to the plugin codebase. In case it's useful for folks, here is the background on why I'm wanting to do this. I'm using this mechanism to be able to create patch projects/artifacts for artifacts that only include the source for classes that are updated for that patch. These patch projects designate the project/artifact being patched as a parent. The patch project only contains the sources and unit tests for functionality that has been modified / added in the patch. The jar generated by these projects only have the patched classes and I can apply this patch by placing this jar ahead of the actual artifact's jar, in the classpath, in an installation. Along with running the unit tests that I have created for the patch, I do want to be able to run all the unit tests for the project/artifact being patched, so that I can verify that the entire project continues to work, as expected, with the changes. Through this mechanism I have that ability. Ofcourse, the artifact being patched has to export it's to the maven repository, so that the patch project can depend on it, but that's easy. Cheers, Anshul On Thu, Mar 26, 2009 at 1:57 PM, Anshul Jaiswal <ans...@marketcetera.com>wrote: > Thanks for your replies, Brett and Stephen! > > I was able to use the @RunWith with a Suite subclass that would search for > unit tests within jars in the classpath. However, the problem with that > approach is that all the unit tests run within the same JVM. Whereas we want > all the unit tests to be forked, pretty much like forkMode=always. > > Looking through the code, it appears to me that I can write my own subclass > of org.apache.maven.surefire.suite.AbstractDirectoryTestSuite and override > its locateTestSets() method (actually I just want to override collectTests() > but that is private) to be able to implement my own test discovery > algorithm. > > However, it's not clear to me how I can get surefire plugin to use my > subclass instead of the Junit one. I guess I may have to create my own > surefire-provider? I guess I can do that by starting with (or extending) the > junit4 provider. Lets say I do that how, is there a way to get surefire to > use my provider instead of junit 4. > > Cheers, > Anshul > > > > > On Fri, Mar 20, 2009 at 1:53 PM, Anshul Jaiswal > <ans...@marketcetera.com>wrote: > >> Folks, >> >> The surefire plugin currently supports automatically searching for unit >> testing classes from a directory. >> >> I was wondering if there is way for it to search for unit tests from a set >> of jar files instead of a directory. ie., a mechanism where I can specify a >> regex pattern for the package and/or class name and it can search through >> all the jars in the 'test' scope for classes matching that pattern and run >> them. >> >> Thanks in advance! >> Anshul >> > >
