Section 1.5. Writing a Test

1.5. Writing a Test

We'll finish each chapter with a test. In fact, if you're a true believer in test-driven development, you should code your test cases first. Many of you bought this book because Spring can improve the testability of your applications. In fact, improving testability was one of the fundamental drivers of Spring's architecture from the beginning.

Automating your tests gives you more confidence that your code will work right, and will keep working right as you make changes. In fact, our managers are all reading the same books that say that it's expensive to keep large testing organizations in place. We've got to pick up the slack. There's no effective way to do that without automation. There's a big problem, though. Many of our current development architectures, like EJB and Struts, do not support testing very well. They're expensive to load, and hard to mock.

Spring changes all of that. Each object can run outside of the container. Further, since the container itself is so light, the startup cost is negligible. That's a huge win for you, if you want to test. Finally, Spring encourages designs with very loose coupling between components.

1.5.1. How do I do that?

Think of a unit test as another client of your application. The test makes assertions about what should be true should the application be working correctly. For example, if you add an object to a list, the size should increase by one. Then, you can run the test standalone while you're building a new feature or debugging an old one. You can also run the tests as part of the overall build. If the tests fail, then the build fails.

Each test case is a subclass of TestCase. In Example 1-11, the test will be a client of the façade.

Example 1-11. RentABikeTest.java

public class RentABikeTest extends TestCase{     private RentABike rentaBike;     public void setUp( ) {         rentaBike = new ArrayListRentABike("Bruce's Bikes");     }          public void testGetName( ) {         assertEquals("Bruce's Bikes", rentaBike.getStoreName( ));     }     public void testGetBike( ) {         Bike bike = rentaBike.getBike("11111");         assertNotNull(bike);         assertEquals("Shimano", bike.getManufacturer( ));     }     public void testGetBikes( ) {         List bikes = rentaBike.getBikes( );         assertNotNull(bikes);         assertEquals(3, bikes.size( ));     } }

Next, you'll need to modify Ant to run the tests. Example 1-12 gives the additional task to compile the test (note that you'll have to modify PATH_TO_JUNIT to be appropriate for your environment).

Example 1-12. build.xml

<property name="test.class.dir" value="${test.dir}/classes"/> <path >      <fileset dir="${spring.dir}/dist">           <include name="*.jar"/>      </fileset>      <pathelement location="${spring.dir}/lib/jakarta-commons             /commons-logging.jar"/>      <pathelement location="${spring.dir}/lib/log4j/log4j-1.2.8.jar"/>      <pathelement location="${spring.dir}/lib/j2ee/servlet.jar"/>      <dirset dir="${basedir}"/>      <dirset dir="${class.dir}"/> </path> <path >      <path ref/>      <pathelement location="PATH_TO_JUNIT"/> </path> <target name="compile.test" depends="init"             description="Compiles all unit test source">         <javac srcdir="${test.dir}"                destdir="${test.class.dir}"                classpathref="junit.class.path"/> </target>

Example 1-13 is the task to run the tests.

Example 1-13. build.xml

<target name="test" depends="compile.test, compile"             description="Runs the unit tests">         <junit printsummary="withOutAndErr" haltonfailure="no"                 haltonerror="no" fork="yes">             <classpath ref/>             <formatter type="xml" usefile="true" />             <batchtest todir="${test.dir}">                 <fileset dir="${test.class.dir}">                     <include name="*Test.*"/>                 </fileset>             </batchtest>         </junit>     </target>

Here's the result of the test:

Buildfile: build.xml init: compile: compile.test: test:     [junit] Running RentABikeTest     [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.36 sec BUILD SUCCESSFUL Total time: 2 seconds

1.5.2. What just happened?

Ant just built the entire application, including the tests. Then, Ant ran the tests. All succeeded. If a test case had failed, then you'd have to make it pass before the build could be successful. In this way, you catch small errors before they become larger ones.

In the next chapter, we'll really start to exercise Spring. We'll build a true user interface for this application using Spring's WebMVC. We'll also show you how to integrate existing user interface components into Spring.