• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • paul wheaton
  • Ron McLeod
  • Jeanne Boyarsky
Sheriffs:
  • Paul Clapham
Saloon Keepers:
  • Tim Holloway
  • Roland Mueller
Bartenders:

Testing transactions...

 
Ranch Hand
Posts: 194
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I've been trying to track down some Hibernate/JPA behavior by getting a simple test case. The regular application using OpenEntityMangerInView, and @Transactional annotations on the dao (migrating to a repository pattern).

Most of my tests are true unit tests and hit mocks of the various daos/repositories. I also have a very thin layer of integration tests that test that the dao layer works; so far these test have been very simple and didn't need to worry about transaction semantics.

Now I have a test that is triggering lazy load exceptions, and I'm not sure what's needed in the test environment to get lazy loading to behave in a similar manner as the application.

Here's my test code:

The first getEvents().size() call is where the exception is getting thrown.

Now the dao is very simple (most of it comes from a base class)

The integration tests use a different Spring application context file, but both have identical transaction manager setups.

I beleive the only real difference between my integration test environment and either my full acceptance test environment or production is the OEMIV filter.

How do you establish/deal with transactions in test environments when using Spring annotations to drive transactions in application code?
 
reply
    Bookmark Topic Watch Topic
  • New Topic