Dashboard > Public Content > ... > JavaStuff > Testing Persistent Objects Without Spring
  Public Content Log In   View a printable version of the current page.  
  Testing Persistent Objects Without Spring
Added by James Richardson, last edited by James Richardson on Nov 18, 2007  (view change)
Labels: 
(None)

The Spring fallacy

Spring proponents will have you believe that "Unit Testing" of persistent classes is very hard without spring. This is not the case, and can be accomplished in only a few classes.

This is not spring-bashing - I'm sure that Spring is very useful for some. This is simply an alternative approach to one that was presented at InfoQ

Requirements

To use these examples you will need the following libraries - all open source

Persistance

We will be using a simple annotated class just to show the example.

The Persistent Stuff

This is where you might have used the ejbFindBy methods back in the day... its just an interface.. so you can conveniently have mocks and stubs for them.

And an implementation for the interface

Using an EntityManager. This means that we will create them in the transactional context in which they are used, rather than having them around for ever - as we might have used with an EntityManagerFactory. Short lived objects are very efficent these days.

Transactional Context

If we are to have any hope of using the entity manager outside of a J2EE container, then we need to do so within a transaction. Managing this as part of a testcase is a bit hit-and-miss - better abstract it.

Creating a test Configuration

All systems have some way of getting their configuration. In real code the implementation here would be a little more intelligent.

Creating a test Entity Manager

This example uses Hibernate and Oracle, but you could do this with lots of other implementations. Note that the actual implementation doesn't escape - as far as the rest of the code is concerned, we are still only talking about EntityManagers.

To keep the amount of code in this page short - I used the autoDDL feature of hibernate. I would suggest never do this, and make sure to have a good database rebuilding script as part of the build process. Dropping and recreating databases takes only seconds.

Builders

We like to use the Builder pattern - it makes code much cleaner!

The actual persistence test

How it all looks

Here's a screenshot from IntelliJ after we have put all the code together.

Contact me - using the contact me page if you would like access to the svn repo. All the code is here though.

Screenshot

Thanks

Nat & Nick

Complaints

To me...

This is helpful, thanks for the post. Perhaps your own article on InfoQ next time?

JAW
http://jawspeak.com

Posted by Anonymous at Nov 21, 2007 09:25 | Reply To This

The matcher should be hasSameTransientFieldsAs, not hasSameNonTransientFieldsAs,

Posted by Anonymous at Feb 05, 2008 21:51 | Reply To This

No it shouldn't. Transient fields are not persisted. We are trying to test that the persisted fields are loaded back in correctly.

Powered by Atlassian Confluence, the Enterprise Wiki. (Version: 2.5.1 Build:#806 May 06, 2007) - Bug/feature request - Contact Administrators