In a recent commit to JUnit Kent Beck and David Saff have added an “alpha-ready implementation of
SuiteBuilder”. As Kent Beck previously described in a blog post, the idea behind the
SuiteBuilder runner is to use annotations on fields instead of annotations on classes.
Limitations of regular test suites
While an annotation can take parameters the arguments must be literals, e.g. constant String values or class literals. For example, the classic
Suite runner is configured using the
@SuiteClasses annotation that takes an array of class literals, i.e. the test classes to be run:
Literals have a severe limitation: they must be know at compile-time! Thus, when using the
Suite runner, there was no way of determining the classes to run by any other means such as scanning the current classpath.
ClasspathSuite to the rescue
For this original purpose, Johannes Link created the
ClasspathSuite runner. Its basic usage is very simple: just specify it using the
@RunWith annotation. In addition, you can also include test classes in JAR files, filter by class names or types, and so on:
ClasspathSuite does not support JUnit’s categories as mentioned in an earlier blog post. While it could certainly be extended to support the Category-related annotations
SuiteBuilder offers a more flexible alternative.
SuiteBuilder runner is similar to the
Suite runner, but reads the test classes it is supposed to run from a field of the suite class annotated with
@Classes. The field can be freely initialized to hold an implementation of the
SuiteBuilder.Classes.Value interface which simply wraps a collection of classes. E.g., the first example can be rewritten using the
In addition, you can filter the resulting test runners by annotating a field of type
@RunnerFilter. For example, the latest commit included a
CategoryFilter that filters tests by category:
Putting the pieces together
So what? Well, instead of specifying the classes explicitly you could employ the capabilities of the
ClasspathSuite to determine the test classes dynamically. For this purpose, I have written a small wrapper around Johannes Links’
ClasspathSuite. The above example can thus be rewritten without explicitly specifying the test classes:
The wrapper offers the same flexibility as the
While I will look into how this can be integrated into JUnit or ClasspathSuite feel free to contact me if you are interested in the source code of the
I am currently working on integrating ClasspathSuite and InClasspath into core JUnit… In the meantime, you can take a look at the code on GitHub.