Obviously, you don't want to run the unit tests for an entire application when developing
just one class. TestRunner,
a tool that comes with GrandTestAuto, does the job. For example, to run the unit tests for the class Messages my command is:
java org.grandtest.auto.TestRunner org.grandtestauto.test.MessagesTest
Again, you don't always want to test everything. The trick here is to a main method to your UnitTester class for that package. For example:
public class UnitTester extends org.grandtestauto.CoverageUnitTester {
public static void main( String[] args ) {
UnitTester ut = new UnitTester( args[0] );
boolean b = ut.runTests();
System.out.println( "result: " + b );
}
public UnitTester( GrandTestAuto gta ) {
super( gta );
}
public UnitTester( String classesRoot ) {
super( classesRoot );
}
}
Yes, org.grandtestauto.ant.RunGrandTestAuto is an ANT task for this.
By using GrandTestAuto, you can be sure that your application is thoroughly tested. The documentation for JUnit encourages programmers to only test 'complex' methods, which invariably leads to errors not being found during testing.
Yes, and writing tests is often tedious. However, fixing bugs in released code is a lot of tedious, stressful, embarassing and expensive work.
There are occasions where it's acceptable for a unit test for a method to just return true without testing anything. For example, there might be only a single way of constructing objects of a class, and there might already be enough tests that such objects are well-formed. The point is that using GTA forces developers to justify not testing a method. Such justifications should appear in the test method as comments.
A constructor should create an object that is in a well-defined state. There need to be tests that check that this works. For example, once I was developing a class whose objects were created either from a string or from a database. All of my unit tests for the class used objects created by the string constructor. Even a simple check that database-constructed objects were valid would have saved a lot of time down the track when an error was discovered.
The prospect of having to write hundreds of thorough unit tests in order to start using GTA on a partially complete is daunting indeed. For this reason, there is a way of migrating to the use of GTA. Each package needs a test sub-package, and each of these needs a UnitTester. However, the UnitTester need not extend CoverageUnitTester. Instead, it need only implement org.grandtestauto.UnitTesterIF and have a constructor taking an org.grandtestauto.GrandTestAuto as argument. The UnitTester could run the existing tests, be they JUnit tests, JPython tests, or whatever.
The tool is meant to be run from the command line or automatically as part of a build process. It's not clear that a user interface will add much value to GTA. If you really want one do it yourself or complain.
There is no really good answer to this question. I wanted to make use of the Java 1.4 and 1.5 language features when developing GTA. If you want a Java 1.4 version, download GTA version 1. If you want a JDK1.3 or JDK1.2 compatible version, then fiddle with the source code and re-compile, or complain. If there are enough complaints, I'll release a JDK1.2-compatible version.
In some ways, it would be better if GTA were to search a jar for the classes to be tested. After all, a jar is usually the released form of java software. The reasons that a classes directory, rather than a jar, are searched, are: