Cleaning Up the Code

I l @ ve RuBoard

The rest of the methods in Listing 8.4 are straightforward, almost cookie- cutter . Compiling the finished file generates no errors, so you're mostly done for now with Customer.java. However, you need to practice some due diligence to avoid difficulties down the road.

Javadoc

All public methods need to have Javadoc written for them. As has already been pointed out, writing Javadoc is outside the scope of the book and has been left out of the printed examples to keep the page count inside the realm of sanity . However, you'll find full Javadoc in the source files found on the Web site.

Unit Tests

Unit tests are standalone tests that thoroughly exercise one particular piece of functionality. They are useful because they allow developers to make sure that all of the functionalities of their subsystems are working properly, independent of the application as a whole.

You should also put in a unit test for the class, if at all possible. When you start to develop complicated applications, especially J2EE and EJB applications, it could take 15 or 20 minutes to start up the full server. If problems occur in newly written code, it can be nearly impossible to track them down. Writing unit tests that can be run from the command line lets you quickly determine whether your code does at all what you expected. This has come in handy several times when my code was thought to cause an error, and I was able to demonstrate that it passed the unit test.

In this case, you can write a unit test if you hard-wire in some values to simulate input from outside functions calling into the class and to do the initializations on the connection pool that otherwise would be handled by the server startup (see Listing 8.5).

Listing 8.5 Yet More Additions to Customer.java

 public static void main(String[] args) {   TurbineConfig tc = new TurbineConfig("com/bfg/props/",                                         "TurbineResources.properties");   tc.init();   Customer c = new Customer();   c.setLastName("NameThatShouldNeverBeUsed");   c.setFirstName("Joe");   c.setPassword("easilyguessed");   c.setEmail("[e-mail]");   try {       c.createCustomer();       System.out.println("Good Test: Create Customer");   } catch (Exception e) {       System.out.println("Failed Test: Create Customer");       e.printStackTrace();   }   try {       c.createCustomer();       System.out.println("Failed Test: Create Duplicate Customer");   }  catch (DuplicateEmailAddressException e) {        System.out.println("Good Test: Create Duplicate Customer");   }  catch (Exception e) {        System.out.println("Failed Test: Create Duplicate Customer");        e.printStackTrace();   }   try {       Customer c1 =           findCustomer("[e-mail]");       if (c1 != null) {           System.out.println("Good Test: Find Real Customer");       }  else {            System.out.println("Failed Test: Find Real Customer");       }   } catch (Exception e) {       System.out.println("Failed Test: Find Real Customer");   }   try {       Customer c1 =           findCustomer("[e-mail]");       if (c1 != null) {       System.out.println("Failed Test: Find Fake Customer");          } else {               System.out.println("Good Test: Find Fake Customer");          }   } catch (Exception e) {       System.out.println("Failed Test: Find Fake Customer");   }   try {       c.deleteCustomer();       Customer c1 =           findCustomer("[e-mail]");       if (c1 != null) {           System.out.println("Failed Test: Delete Customer");       } else {            System.out.println("Good Test: Delete Customer");       }   } catch (Exception e) {        System.out.println("Failed Test: Delete Customer");   } } 

This does what a good unit test should do ”it exercises all of the functionality of the class (at least, the parts that aren't boilerplate , such as get and set methods). It is also careful to leave the database in the same state that it was found so that it can be run repeatedly. You need to add the Turbine configuration calls at the top because this does not run through Tomcat, so it will not get the initializations during startup.

Getting the unit test to run is a bit tricky, however, because it depends on subsystems such as Turbine being properly configured. You conceivably could invoke it by hand, but that would be quite tricky because you'd need to set up configuration elements such as the classpath perfectly each time you wanted to invoke the test. Instead, put some more targets in your Ant script to let you automatically invoke all of your unit tests. This also will come in handy when regression testing starts. Here's some code to do just that, in Listing 8.6.

Listing 8.6 Additions to build.xml

 <target name="test" depends="dist">    <java classname="com.bfg.customer.Customer" fork="yes">      <classpath>      <pathelement path="${java.class.path} "/>        <fileset dir="c:\tomcat\lib">          <include name="**/*.jar"/>        </fileset>        <pathelement path="src"/>      </classpath>    </java> </target> 

Because this code will run from the base directory, and because TurbineConfig looks for its property file relative to where the Java executable is started, you need to specify the path in the TurbineConfig call as com/bfg/props/ so that it can find the file successfully. You also should have the Ant script configure Java to add the src directory to the class path so that it finds the class files to test.

When you run the unit test with ant test , you get the desired result:

 C:\CARTAPP\bfg>ant test Buildfile: build.xml init: compile: dist: test:      [java] Turbine: init      [java] Turbine: Turbine: init() Ready to Rumble!      [java] Good Test: Create Customer      [java] Good Test: Create Duplicate Customer      [java] Good Test: Find Real Customer      [java] Good Test: Find Fake Customer      [java] Good Test: Delete Customer BUILD SUCCESSFUL Total time: 1 second C:\CARTAPP\bfg> 

If you don't get this result, either your database is set up incorrectly, you're not connecting to it correctly, or your SQL statements are in error.

I l @ ve RuBoard