CSC223, Class 18: JUnit

Admin:
* Convo tomorrow (in Harris)
* I know more about Swing than I realized 
* Homework questions?  Now due Monday.
* Did anyone do the reading?  (Barely)
* Warning!  Today's topic switched from Swing to JUnit

Overview:
* Questions on the Homework
  * Can I have an extension?
  * How do we use JUnit?
* Hash tables

About JUnit
* Context: We were talking about ways to test Points.
* Conclusions about testing:
  * Gather errors into a vector and then spew 'em out at the end.
    * Those errors might be exceptions, so we can catch them.
    * Those exceptions might also show us the context of the error
  * Test program should exit with 0 for success and 1 if there are any errors.
* JUnit works with these ideas
  * Your test classes extend TestCase
    * Note: If we have a subclass of TestCase that permits you to add multiple TestCases, you can combine tests
  * Your test classes provide methods called testFOO
  * Your test classes should provide a static method called
     suite() which return a TestSuite
  * Your test methods contain a number of calls to assertTrue(boolean) or assertEquals(X,X)
* Key package junit.framework.
* To run JUNit, make sure that
	/usr/share/java/junit.jar
  is on your classpath
* Question: If we program in a non-XP way, we design interfaces first and then one or more implementations for those interfaces.
  * Can we design tests for interfaces and "immediately" extend them for the implementations?
* If you include a method called setUp (note capitalization), JUnit calls it before each test.
* Observation: A test is likely to need to create lots of objects.  How can we write a test in the interface if there is no constructor?
  * Factory methods!
  * In this particular case: Make the test an abstract class and include an abstract factory method called create() (or some such)

/Detour: Abstract Classes/

* Observation: Sometimes you want something that falls between interface and class
  * It implements some methods
  * But not all methods
* Examples:
  * Test program for interfaces that doesn't want to specify how the individual objects are created
  * Vec2D, potentially, since we can use the same equals method independent of implementations
* Something that specifies some of the implementation, but not all of the implementation, is an "abstract class" (in Java)
  * Write the keyword "abstract" before the word "class" in the declaration
  * Write the keyword "abstract" before any undefined method in the body
* You usually have to subclass the abstract class (implementing any abstract methods) before you can do anything with it.
  * Use the keyword "extends"
* Abstract classes frequently come from refactoring

/Moral about hash tables/

If you are using objects of type Foo as keys, then
* Foo must implement hashCode
* Foo must implement equals
* Objects in class Foo should be immutable