Announcement Announcement Module
Collapse
No announcement yet.
Simulate OpenSessionInView in JUnit? Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Simulate OpenSessionInView in JUnit?

    Hello group,

    I was very happy to discover Spring's support for JUnit testing via the AbstractTransactionalSpringContextTests. Very cool stuff. Worked like a charm, and I can now discard my SpringEnabledTestCase

    The setup is properly demarcating my transactions, just like in my web container, but there seems to be no equivalent for keeping the session open past a commit. My test methods are more like integration tests, and as such require post-commit sessions for lazy-loaded collections.

    How do I achieve this? I dug up a few references to some code which allows this, but it all seems to be pre-1.0 Spring code and doesn't even mention the AbstractTrans.... base test classes.

    TIA,

    Chris

  • #2
    Hi
    I tried the following and it works fine for me. I don't know if it will work in your case or if you've already tried it ...

    Code:
    public void setUp() throws Exception {
    	    super.setUp();
    	    SessionFactory sessionFactory = (SessionFactory) getBean("sessionFactory");
    	    Session s = sessionFactory.openSession();
    	    TransactionSynchronizationManager.bindResource(sessionFactory, new SessionHolder(s));
    
    }
    
    public void tearDown() throws Exception {
    	    super.tearDown();
    	    SessionHolder holder = (SessionHolder) TransactionSynchronizationManager.getResource(sessionFactory);
    	    Session s = holder.getSession(); 
    	    s.flush();
    	    TransactionSynchronizationManager.unbindResource(sessionFactory);
    	    SessionFactoryUtils.closeSessionIfNecessary(s, sessionFactory);
    }
    regards,
    Mario

    Comment


    • #3
      That looks like it will work, but my test cases extend AbstractTransactionalSpringContextTests which declare setUp() and tearDown() final. Are you handling your own Spring setup and transaction commit/rollback?

      -Chris

      Comment


      • #4
        Oh, you're right - sorry.
        In this case you could try to extend AbstractDependencyInjectionSpringContextTests and override onSetUp() and onTearDown(). But then you'd have to rollback manually.
        Maybe binding/unbinding the session in your run() method would work too, but i don't think this is a fine solution.

        Mario

        Comment


        • #5
          It seems like this should be part of those base TestCases. Maybe I will submit a patch and see how it goes. Is there any logical reason why this functionality would be left out of the base classes, other than the possibility that nobody has taken time to add it yet?

          Comment


          • #6
            I guess I'm a little confused here. If I'm using declarative transaction demarcation, and my transaction manager and interceptor are configured in the very same XML file I use at runtime, do I even need a transactional base TestCase, or is this going to create a nested transaction situation?

            All I really need is for the session to stay open from setUp() to tearDown().

            Sorry for the newbie ignorance!

            -Chris

            Comment


            • #7
              You can of course use a simple JUnit TestCase here (thats what i'm doing). According to the javadoc "you should not normally use the Spring container for unit tests".

              I'm not sure if there would be a nested transaction situation - maybe somone else could help us there.

              Comment


              • #8
                Solved!

                Thanks for all your help, nyname00. I did indeed extend AbstractDependencyInjectionSpringContextTests and used almost the same code you provided. The key is to NOT used the Transactional test case, that will bomb on the tearDown() because Spring will have already flushed and unbound the session when a declared transaction finishes (at least that's what it seems like).

                As I mentioned, my JUnits are more like integration tests, so I need to have the support for my business methods that are declaratively demarcated. I agree, typical unit tests should not rely on the Spring container.

                Thanks again!

                Comment

                Working...
                X