Unit test for CayenneClinic (Spring integration demo) -- DataContext binding to threadlocal?

From: Paul Furbacher (pfurbache..ac.com)
Date: Thu Jun 02 2005 - 14:39:48 EDT

  • Next message: Mike Kienenberger: "Re: Unit test for CayenneClinic (Spring integration demo) -- DataContext binding to threadlocal?"

    First, thanks to Andrus for writing the Spring/Cayenne integration
    pieces.

    After some struggle to create and configure a JBuilder project for the
    Spring-on-Cayenne demo (yes, I could just use the Ant build.xml but
    it's more satisfying to have a complete project), I've been able to
    run the Web app, but more importantly, write a unit test for
    CayenneClinic. (I was surprised to see that this wasn't a part
    of the demo, since unit testing with Spring integration has to
    be a bit different in the setup part.) The point of the exercise
    was not to test CayenneClinic so much as to see how one would do
    the setup so that tests could be run. The idea was to use the
    same applicationContext-cayenne.xml, and other configuration files
    to set up the dependencies.

    But I got stuck on how to create and provide the DataContext in a
    manner similar to which the WebInterceptor does. For a stand-alone
    app (i.e., not a Web app), it seems as though there should be an
    equivalent to WebInterceptor, but I'm not able to implement such
    a beast, given my weak understanding of both Spring and Cayenne.

    Erik Hatcher's May 5, 2005, message on unit testing was helpful in
    that it provided a solution for creating a DataContext and properly
    putting it into a ThreadLocal (not exactly sure what that means).
    But a more elegant approach would be to have Spring do this all
    as a part of a call to new ClassPathXmlApplicationContext().

    Below is a simple unit test, one which uses visual inspection of
    the data instead of assertXXXX. Note the use of

       DataContext.bindThreadDataContext(DataContext.createDataContext());

    in "getApplicationContext()".

    I'd like to obviate the need for that statement with a generalized
    applicationContext configurable "interceptor", or whatever it should
    be called. Any ideas?

    Thanks.

    Paul Furbacher

    ***
    package org.springframework.samples.petclinic.cayenne;

    import [...];

    /**
      * <p>A simple unit test for CayenneClinic -- more of a test of
      * concepts related to setting wrt Spring app context config.
      * </p>
      *..uthor Paul Furbacher
      *..ersion 1.0
      */
    public class TestCayenneClinic extends TestCase {
       private Clinic clinic = null;
       private ApplicationContext appCtx;

       public TestCayenneClinic(String name) {
         super(name);
       }

       public ApplicationContext getApplicationContext() {
         // This shouldn't be necessary if a Spring "interceptor" existed.
         DataContext.bindThreadDataContext(DataContext.createDataContext());

         String [] paths = new String [] {
             "applicationContext-cayenne.xml",
         };
         return new ClassPathXmlApplicationContext(paths);
       }

       protected void setUp() throws Exception {
         super.setUp();
         // We don't do the following because we want Spring to hand us
         // a preconfigured bean.
    // clinic = new CayenneClinic();

         appCtx = getApplicationContext();
         if ( appCtx != null ) {
           clinic = (Clinic) appCtx.getBean("clinic");
         }
       }

       protected void tearDown() throws Exception {
         ...
       }

       public void testFindOwners() throws DataAccessException {
         Collection actualReturn = clinic.findOwners(lastName);
         if ( actualReturn != null ) {
           for (Iterator iter = actualReturn.iterator(); iter.hasNext(); ) {
             Owner item = (Owner) iter.next();
             System.out.println(" " + item.getFirstName() + " " +
    item.getLastName());
           }
         }
    // assertEquals("return value", expectedReturn, actualReturn);
         /*..odo fill in the test code*/
       }

       // more tests deleted ...

    }
    ***



    This archive was generated by hypermail 2.0.0 : Thu Jun 02 2005 - 14:39:54 EDT