Announcement Announcement Module
No announcement yet.
Is it possible to unit test a JDO-based DAO? Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Is it possible to unit test a JDO-based DAO?

    I posted a a few weeks ago. I'd like to write up some unit tests for my JDO based DAOs. My new understanding is that unit tests should not require a transaction or database access (or even Spring) and should essentially mock objects that are needed. However, since I'm using JDO, so in some cases I'm calling static functions in JDOHelper and in others I'm getting a PersistenceManager from up the hierarchy (in the code maintained by Spring).

    I can't see how I would mock static functions in a library-provided class, or how I could mock objects returned by superclass functions. Is this a situation where unit testing simply doesn't work and integration testing is the only way to cover the code? Or is this a situation where my code is "simple enough" to not require unit testing?



    Here are some examples of functions that would be tested:

        public final void storeAccessControl( final AccessControl accessControl )
            Object controlObjectId = null;
            // If the object being stored is a detached object, get the object id. By definition, new
            // objects are not detached.
            if( JDOHelper.isDetached( accessControl ) )
                controlObjectId = JDOHelper.getObjectId( accessControl );
            JdoDaoUtil.storeObject( this, accessControl, controlObjectId );
        public final Collection<AccessControl> findAccessControlList(
            final AclSecurable aclSecurableObject )
            String queryName = "ACLByObjectId";
            Query q = getPersistenceManager().newNamedQuery( DefaultAccessControl.class, queryName );
            Collection<AccessControl> foundControls =
                (Collection<AccessControl>) q.execute( aclSecurableObject.getDomainObjectId() );
            return( (Collection<AccessControl>) getJdoTemplate().detachCopyAll( foundControls ) );
    Last edited by robyn; May 14th, 2006, 10:10 AM.

  • #2
    Take a look at the integration testing support from the reference documentation (the end of documentation). This means that you'll start doing integration testing rather then unit tests - this way you can work directly on the database. It will be slower but this way you don' t have to simulate the behavior of the framwork you are working with.


    • #3
      I strongly second Costin's point. Unit testing DAO implementations is typically a lot of work and doesn't test what you really want to test: JDO QL queries, SQL etc.

      Integration testing is not even necessarily slow due to the optimizations in the org.springframework.test package.