Testing

In your projects, you are required to meet three requirements with respect to testing.

All major functionality covered in unit tests.
By major functionality, we mean nearly everything that couldn't be automatically generated by a dumb IDE. You may safely exclude accessors and other very short methods. Moving beyond single functions, you may also wish to test the integration of objects. While not a panacea, code coverage tools may be of use in this regard.
All included unit tests must pass
Please do not submit any failing tests. fail("unimplemented") is not a test. If you have test cases that rely on external files, please make sure they exist in SVN. In fact, check out a fresh copy of your source tree somewhere else and make sure you can build, run, and test your code as you describe in your README.
Testing must be automated
There are several ways to achieve automation. Our preference is that you create a suite called AllTests. With JUnit, simply fill in the blanks:
JUnit 4
import org.junit.*;
import org.junit.runner.*;
import org.junit.runners.*;

@RunWith(value=Suite.class)
@Suite.SuiteClasses(value=
    UnitTest1.class,
    UnitTest2.class,
    IntegrationTest1.class,
    ...
    })
public class AllTests {
}
                        
JUnit 3
import junit.framework.Test;
import junit.framework.TestSuite;

public class AllTests {
        public static Test suite() {
        TestSuite suite = new TestSuite("Fancy pants test suite");

        suite.addTest(UnitTest1.suite());
        suite.addTest(UnitTest2.suite())
               ...
        return suite;
	}
}
                        
You are free to roll your own automated solution using make, shell scripts, PostScript, pandas, or anything else to which the graders have access. However, we do strongly suggest the above solution for one simple reason: most code coverage tools integrate with JUnit suites. You and I will both be in a better mood if we don't have to toss something else together just to see loop coverage stats.

Suggestions

Beyond these requirements, we have a few suggestions.

Write tests with the code being tested.
The intended behavior of the code you're writing is typically freshest when you're hacking it out, right? So why wait to verify that it works? When you write that whiz-bang method to parse gzip headers or perplex a player, write up some testing code. Even better, swap the keyboard out to your partner so two of you know what's supposed to happen and can catch failed attempts. Think of it as a free code review.
Think about corner cases.
Verifying that you get the correct answer when given reasonable input is great, but don't stop there. What happens when you try to TAKE a door, USE a person, or give gunzip a jpeg? Spend a moment to think about the garbage the graders may throw at your software to try to produce a stack trace.
Use a code coverage tool.
There are many Java packages to figure out how extensive your tests are. Pick one and use it. While 100% coverage of all statements, conditional bodies, and loops would be amazing, we recognize there is a point of diminishing returns. For the purposes of COMP 314, let's say it's 70%. Shoot for that level of coverage and I guarantee you'll catch bugs through testing.