Test Suites

Do you setup test suite for your tests? My company has ended up doing it by package. What I would like to setup would be one huge test suite that would perform like ant scripts (which we have setup but not many of our programmers have access too) where when they make a change that they think may cause problems elsewhere, the person could run this locally. Also, run one suite across projects? Possible or just dreaming.

What is the test suite BTW?

I believe it's the collection of all tests.
It's what can be called from the GUI or the textual interface to run all your tests.
Here's an example of my test suite.
You'll see the main that calls the tests first, followed by the suite.
Note that all the individual unit tests are within each class of the suite (i.e. ClasExpMonthsTest.class contains all the individual unit tests for that class) and JUnit uses introspection to find all the tests.

Originally posted by Greg Ostravich:
I believe it's the collection of all tests.
It's what can be called from the GUI or the textual interface to run all your tests.

Exactly, but have tried to combine tests from other projects. I think maybe having a testsuite that call all the project test suites. I am still trying to come up with the best design to be able to do it so if anybody has tried to do this please let me know. Thanks...

Do we use junit.textui.TestRunner.run (TestClass.Class) for testing all the test in the TestClass and junit.textui.TestRunner.run (suite()); for testing all the classes? :roll:

Thanx

Originally posted by Pradeep Bhat:
Do we use junit.textui.TestRunner.run (TestClass.Class) for testing all the test in the TestClass and junit.textui.TestRunner.run (suite()); for testing all the classes?

Yes, the run(Class) method uses the Reflection API to pick up all JUnit test methods from the given class and executes those tests.

However, what the run(TestSuite) method executes depends on what the given TestSuite object returns from its static suite() method. A typical implementation for a TestSuite is to manually construct a list of all children of TestCase in the package (see Greg's example class). It is also a convention to name this kind of TestSuites as "AllTests" similarly to how you name all your TestCases as "_________Test".

We have a test suite for each project (that uses reflection to pick up all the tests). A project is a group of packages in Eclipse/WSAD. We also have a master test suite for the project as a whole (a project from a business point of view) that runs all the test suites.

Lasse and Jeanne.

Originally posted by Jeanne Boyarsky:
We have a test suite for each project (that uses reflection to pick up all the tests).

May I ask how have you implemented this reflection-based test suite? Is it something you've written yourselves?

Lasse,
Well, I personally cut and pasted it from someone else at our company. But basically, it gets all the classes using the test collector for the junit api. It then filters by package name (so you don't run the tests in other projects or jar files if you don't want to.) It also checks to see if the class is abstract and then skips it.

Originally posted by Jeanne Boyarsky:
basically, it gets all the classes using the test collector for the junit api.

Do you mean junit.runner.ClassPathTestCollector? Sounds cool.

Lasse,
That's the one! I like it because you don't have to remember to add classes to the "master" suite.

Yeah, me too. Thanks for introducing me to this little gem

It is a collection of all test cases,test data and test environment including all the modules for entire project, which is maintained by any sofware configuaration tool like VSS.

Originally posted by lakshmi bvr:
It is a collection of all test cases,test data and test environment including all the modules for entire project, which is maintained by any sofware configuaration tool like VSS.

Again, it depends on the context. A TestSuite in association with JUnit is a collection of Test instances and nothing more.

Here's something I wrote for Agile Java. The design is driven by tests (not shown) and the fact that JUnit is a legacy mess. createClass is called twice, but you could optimize by caching the class if necessary.



At a client site, Jeff Bay and I paired on a more sophisticated version that covered pattern-based package exclusions (e.g. ignore anything in *.performance) and that read a list of classes to be explicitly ignored. The problem with ignoring tests is just that--often they are forgotten completely!

I look forward to a rewrite of JUnit that takes advantage of the new annotation types in Java 1.5, a la NUnit. I modified JUnit to support an @Ignore tag and can show in the swingui a tab of all test methods marked with @Ignore.

-Jeff-
[ June 02, 2004: Message edited by: Jeff Langr ]

Originally posted by Jeff Langr:
I look forward to a rewrite of JUnit that takes advantage of the new annotation types in Java 1.5, a la NUnit. I modified JUnit to support an @Ignore tag and can show in the swingui a tab of all test methods marked with @Ignore.

Actually, Cedric Beust has already wrote one called TestNG and it is compatible with JUnit.
[ June 02, 2004: Message edited by: Chris Mathews ]

Excellent, thanks for posting the link!