Exploring core JUnit - JUnit in Action - page 23

public class TestSuiteA {
}

[...]
@RunWith(value=Suite .class )
@SuiteClasses(value = {TestCaseB .class })
public class TestSuiteB {
}

[...]
@RunWith(value = Suite .class )
@SuiteClasses(value = {TestSuiteA .class , TestSuiteB .class })
public class MasterTestSuite{
}

Our simple test suites TestSuiteA and TestSuiteB have only one test case each, a sim-
plification to abbreviate this example. A real suite would contain more than one test
class, like our master suite.
You can run any of the classes in this listing as a JU nit test, one of the two test
classes, one of the two test suites, or the master test suite. Figure 2.2 displays the result
of running the master suite in Eclipse.
Test suites provide a powerful way to organize your tests. The convenience isn't
unique to JU nit, as you'll see in the next section, which will make us reconsider creat-
ing any JU nit suites at all.

2.4.3 Suites, IDEs, Ant, and Maven

Ant and Maven also provide ways to run groups of test classes and suites by allowing
you to specify, with a type of regular expression, the names of test classes and suites to
run. In addition, IDE s like Eclipse allow you to run all test classes and Suite s in a
selected package or source directory. This is enough to make us reconsider whether
it's worth creating JU nit Suite s in the first place.
JU nit Suite s are useful if you want to organize your tests in Java, independent of
the capability of your build system, because it's common for someone or a group
other than the developers to maintain builds. Similarly, you may wish to provide inde-
pendence from any given IDE and its JU nit integration capabilities.

Figure 2.2
Running a suite of suites in Eclipse