[link|http://www.xprogramming.com/software.htm|The mother lode of testing frameworks].

I do a lot of Java unit testing. Here's how I break it down:

1) One matching unit test per class. If the class is Foobar.java, then I have a FoobarTest.java.

2) One suite of tests per package. The suite is a Java unit test that can group other unit test classes. If the package were com.spork.stuffies, with a Foobar.java and a Moobar.java, then I'd have FoobarTest.java, MoobarTest.java, and a StuffiesSuite.java that simply incorporates the FoobarTest and MoobarTest. The tests would all go into the com.spork.stuffies.test package.

3) Within a unit test, I have a set of test methods. The breakdown varies depending on functionality; typically I will group them by function; ie. in the list test class I have a testCreate to test the constructors, testParse to test the parsing, etc. Within each of those methods I will have a series of "make this call, then test the results" blocks. I make use of unique descriptive strings passed with each assert to be able to nail down where a particular test method fails.

4) The need for setup and teardown will affect the number and kind of methods in the unit test class as well. If there is a fair amount of setup, and it has to be done fresh before a test, then that test should have it's own method. The setups and teardowns get run before each test method in the test class.