-
Notifications
You must be signed in to change notification settings - Fork 3.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Automatic discovery of @Category annotations #244
Comments
FYI: After testing, the annotation filter cannot be left out of spring's scanning provider. If it's left out the scanner doesn't find any classes. |
Have you seen ClasspathSuite? http://johanneslink.net/projects/cpsuite.jsp |
If you still wanted to use JUnit4-style categories, you could do:
And then do:
This assumes that your suite classes end in "Tests" ("FastTests", "SmokeTests", etc) while your other tests end in something else ("ServerTest", etc) |
Yes, we want to use categories. We also have a load of legacy tests that we don't want to rename. I'm aware of ClasspathSuite, but it really didn't meet our news for those reasons. |
I have tried your solution and found that it would probably work for us: @ClassnameFilters({".*Test"}) } However, the one issue I saw was where the test suite classes lived. I wanted to make a seperate module to define the different categories: @category(FastTestCategory.class) And then create a shared test suite for running them: @RunWith(Categories.class) } The problem I encountered was that if FastTestSuite was brought into the module via a maven dependency, and then my individual tests were in the current module, no tests were run when I tried to execute that suite. I'm not sure if this is a classloading issue or just a maven issue. If i try to run any suite not immediately in the current module, no tests get executed. But if i move that suite to the current module it's fine. |
I suggest asking on the mailing list: http://tech.groups.yahoo.com/group/junit/ My guess is if you have tests in a different module, then they will be in a jar, so will get filtered out by @IncludeJars(false), but that's just a guess. The general idea is you can use a reflection-based suite builder to find all of your tests, and then use Categories to select which ones to run. |
I tried changing includeJars to true, with no luck. I think the problem is that the suite is in a jar file, and the tests are not. So the surefire plugin is getting confused due to it's classloader. It works fine in eclipse. |
I was hoping to have the suite in a single place, the groups support in junit is kind of tacked on after the fact, and isn't truly native to junit. I'd love just to be able to say: mvn test -Djunit.groups=FastTest and be done with it, but alas, i have to create classes to represent the stuff, and create a suite to run it. As a result, in order to be able to just run the FastGroup group for a multi module project, I have to replicate the same suite in every module, and it would have to have the exact same classname. Then i run: mvn test -Dtest=com.myorg.FastTest Just a maintenance headache. |
These sound like mvn issues. Have you tried asking on the mailing list? |
Hi all, i created an issue with an explanation and a solution. https://github.com/KentBeck/junit/issues/307 @mattinger |
@mattinger, some things are getting fixed with respect to Category support, although we still don't have an internal answer to ClasspathSuite. Is this a continuing issue for you? |
Hello, I too would very much like some automated discovery of categories of some sort in the core JUnit framework. Other solutions such as the wildcard based classpath scanning are available, but none seem to be part of JUnit itself. I would also prefer a solution that uses annotation metadata (such as these categories), or maybe both would be interesting. I came across this issue while examining the JUnit categories but I find it inconvenient that one must always enumerate each class using the @SuiteClasses annotation, because this is easily forgotten. |
@marcphilipp, that could certainly be useful. |
@marc Need help? We could do a session at Socrates... Von meinem iPad gesendet
|
I regret that I don't have the energy to participate in this right now. But I'll be following along. |
@jlink We can take a look at it there for sure. Now I just have to |
It would be great if I did not have to specifically enumerate all the test classes in a test suite in order to run a specific category. It seems counter intuitive. The only use that @category really has at that point is at the method level, not at the class level.
I came up with a spring based solution (doesn't really require much of spring, but it uses some spring utility classes, in particular ClassPathScanningCandidateComponentProvider). Perhaps something similar could be implemented in JUnit. The downside to this of course is that the @category annotation (or some other annotation) has to be at the class level in order for the class to be found. That being said, we might be able to leave out the filter on the scanning provider, though you run the risk of pulling in too much if you do that.
@RunWith(DiscoverCategories.class)
@IncludeCategory(Foo.class)
@ScanPackage
public class MyTestClass { ... }
And in DiscoverCategories class it's relatively easy to find all the classes in the classpath with the @category annotation:
The text was updated successfully, but these errors were encountered: