Junit | Category | Accept string value instead of class

[muralidh]

Hi,

I am using junit 4.9 along with maven surefire plugin for running test cases belonging to a particular group.
Similar to testng, can we have junit category accept string values in addition to/instead of just classes ?

This is creating problem when we have a multi module maven based project and we define plugin config in the parent pom, the category class mentioned in the parent pom wouldnt have loaded yet and throws ClassNotFoundException.

Else, we will have to repeat the plugin config in all the sub-modules which is redundant.
Are there any advantages of accepting a class instead of String in org.junit.experimental.categories.Category ?

Thanks,
Gayathri

[Tibor17]

i think this we have is much better than TestNG, because the class inheritance also works in Categories.
How the class inheritance would be otherwise without classes or interfaces -object reference types.

No you don't have to repeat the plugin. Do you know tag pluginManagement ?
So do it there for parent and let the children modules inherit from parent's plugin management. All you have to do in tag plugin children POM is to use groupId, artifactId. No version, no config because this will be inherited from parent's plugin management.

[muralidh]

Thanks for the reply Tibor. I already tried pluginManagement config. But build fails with the same ClassNotfoundException, while parsing the parent pom.

Thanks,
Gayathri

-----Original Message-----
From: Tibor17 [mailto:reply@reply.github.com]
Sent: Monday, March 19, 2012 9:34 PM
To: Muralidharan, Gayathri
Subject: Re: [junit] Junit | Category | Accept string value instead of class (#400)

i think this we have is much better than TestNG, because the class inheritance also works in Categories.
How the class inheritance would be otherwise without classes or interfaces -object reference types.

No you don't have to repeat the plugin. Do you know ?
So do it there for parent and let the cild modules inherit from this management. All you have to do is to use in children with groupId, artifactId. No version, no config because this will be inherited from parent's plugin management.

---

Reply to this email directly or view it on GitHub:
https://github.com/KentBeck/junit/issues/400#issuecomment-4576491

[Tibor17]

so then there must be some other tricky reason in your mvn project
do you use categories as stated in this page?
http://maven.apache.org/plugins/maven-surefire-plugin/examples/junit.html

btw, aren't you using nested classes in categories?
E.g. nested Entry in HashMap will be HashMap$Entry.class on file system

[muralidh]

No. I am not using nested classes in categories. I just wanted to differentiate between unit tests and integration tests so that Hudson CI build time can be reduced by running integration tests once a day. So didnt need nested classes in categories. Needed only one category for identifying integration test alone. Everything else will be unit tests.

Plugin config :
skip.integration.tests property is set in parent pom and is overriden via command line args.

org.apache.maven.plugins maven-surefire-plugin ${maven.surefire.plugin.version} true unit-test test test false -d64 -Xms128m -Xmx4096m -XX:PermSize=512m -Duser.timezone=UTC -XX:-UseSplitVerifier A.B.C.BaseIntegrationTest integration-test integration-test test ${skip.integration.tests} A.B.C.BaseIntegrationTest org.apache.maven.surefire surefire-junit47 ${maven.surefire.plugin.version}

Thanks,
Gayathri

-----Original Message-----
From: Tibor17 [mailto:reply@reply.github.com]
Sent: Tuesday, March 20, 2012 11:34 AM
To: Muralidharan, Gayathri
Subject: Re: [junit] Junit | Category | Accept string value instead of class (#400)

so then there must be some other tricky reason in your mvn project
do you use categories as stated in this page?
http://maven.apache.org/plugins/maven-surefire-plugin/examples/junit.html

btw, aren't you using nested classes in categories?
E.g. nested Entry in HashMap will be HashMap$Entry.class

---

Reply to this email directly or view it on GitHub:
https://github.com/KentBeck/junit/issues/400#issuecomment-4589640

[Tibor17]

@muralidh
I would like to invite you for participating at the code review of the pull req. #142 according to the latest comments.

Tibor

[ggtools]

There's an issue to the use of classes instead of plain Strings. If I want to excluded in the plugin management of the parent pom tests belonging to the what.ever.SlowTests. Since the parent artifact is a pom, I cannot include any java code in it. So if one of the child projects is missing what.ever.SlowTests I'll get a ClassNotFoundException.

May be providing a set of basic categories in JUnit may be a good idea.

[Tibor17]

The children inherit only plugin version and "configuration" in plugin defined in plugin management.
The executions and their configs are not inherited. You must specify it in each child POM.

The point is that you are testing the artifacts, and each artifact is independent, and therefore their tests as well.

That's why modularity, because the child artifact is indivisible, independent and has to have all own like test classes specified in POM's surefire plugin, etc.

So for each child the plugin has to specify its own categories.

For me the mvn works fine. Even the exception is thrown as expected -fix the pom -> children.
But this is about mvn, junit has not a problem, right?

[ggtools]

Sure this is mainly a maven issue but ... I guess including in JUnit some basic categories may be a good thing.

[marcphilipp]

@ggtools Can't you just move your Category classes to a separates Maven module and add that artifact to the dependencies sections in your parent pom (in test scope)?

[ggtools]

@marcphilipp sure but it is quite complicated. Basically, I define the exclusion/inclusion rules in my project parent's pom which cannot include any code. So to define one empty class used to indicate that a test may be slow, I need to create a new project outside of the project's scope. This is a little be complicated. Of course this is a maven issue but I thought it may be valuable if JUnit did provide a bunch of basic categories such as Slow, Integration, Unstable, Whatever.

Just my 2 cents

[pards]

I vote for the solution suggested by @ggtools - add a few standard categories to the JUnit jar.
Failing that, perhaps we can get them added to the junit-dep or surefire-junit47 project.

[ggtools]

As I ran into this issue last week-end I took one hour to upload to the maven central repository a library with basic categories. You can find details on (https://github.com/ggtools/JUnitCategories/wiki)

[Tibor17]

@muralidh
@ggtools
The problem is that exception underneath is thrown while you attempt to read Class object from Annotation like Category#value(). Since your custom category class does not exist in classpath while calling the descriptive method Category#value(), the exception TypeNotPresentException is thrown.

This can be fixed in the method #directCategories() of nested class Categories.CategoryFilter.
We can catch java.lang.TypeNotPresentException and print a warning.

Finally, category which is declared in byte code but missing in classpath will not be considered in annotation declaration. The behavior of Categories runner will be fail-safe in this case.

Would you accept this ?

Exception in thread "main" java.lang.TypeNotPresentException: Type SomeCategory not present
Caused by: java.lang.ClassNotFoundException: SomeCategory

[Tibor17]

@dsaff
The runtime exception java.lang.TypeNotPresentException is thrown through whole stack in JUnitCore and Categories. This happens if a category class does not exist in classpath. So if we catch TypeNotPresentException in Categories and add a failure to RunNotifier, then JUnitCore will execute without throwing exception however pooling failures in Result. Other methods which have categories in classpath will be filtered and executed as usually.
Can I open a pull request for such treatment?

[junit-builds]

JUnit 4 is now in maintenance mode.

At this point, only critical bugs and security issues will be fixed.

The team has therefore decided to close this issue.