Announcement Announcement Module
Collapse
No announcement yet.
AbstractTransactionalSpringContextTests usage Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • AbstractTransactionalSpringContextTests usage

    I want to unit test my DAO's implemented with Hibernate by extending and using the AbstractTransactionalSpringContextTests. I got so far that my subclass is configured properly. I checked that by doing a create, calling the setComplete method and seeing that the transaction was not rolled back.

    I am unsure what a typical testing strategy implementation would look like. Does anybody have experience testing DAO's using the AbstractTransactionalSpringContextTests? Could you post some sample code for typical scenario's: create, delete, update, findAll, findId, etc.?

    Much obliged, Thomas

  • #2
    Maybe this thread could be of some help to you,

    http://forum.springframework.org/showthread.php?t=11691
    Last edited by robyn; May 14th, 2006, 06:46 PM.

    Comment


    • #3
      Thanks. Amkush. It's a good start, though I am using the AbstractTransactionalSpringContextTests and not the AbstractTransactionalDataSourceSpringContextTests.

      One thing that confuses me is the Javadoc for the onSetUp method. I states:

      Subclasses can override this method in place of the setUp() method, which is final in this class. This implementation does nothing.
      But the method is final as well, and cannot be overridden ..??

      Code:
      protected final void onSetUp() throws Exception
      So where should I implement typical setUp logic, that can take place OUTSIDE a transaction? And are onSetUpInTransaction and onTearDownInTransaction callBack methods that are being executed right after starting and right before closing a transaction?

      Comment


      • #4
        Subclasses can override this method in place of the setUp() method, which is final in this class. This implementation does nothing.
        But the method is final as well, and cannot be overridden ..??
        You are looking at javadoc in AbstractDependencyInjectionSpringContextTests. onSetUp is final in AbstractTransactionalSpringContextTests.

        So where should I implement typical setUp logic, that can take place OUTSIDE a transaction?
        Did you consider using the constructor?

        And are onSetUpInTransaction and onTearDownInTransaction callBack methods that are being executed right after starting and right before closing a transaction?
        Yes.

        HTH

        Comment


        • #5
          The quote was taken from the javadoc for the AbstractTransactionalSpringContextTests at http://www.springframework.org/docs/api/.

          Literally it says:

          onSetUp
          protected final void onSetUp() throws ExceptionDescription

          copied from class: AbstractDependencyInjectionSpringContextTests

          Subclasses can override this method in place of the setUp() method, which is final in this class. This implementation does nothing.

          Overrides:
          onSetUp in class AbstractDependencyInjectionSpringContextTests

          Throws: Exception
          Maybe the javadoc can be updated?

          I got my head around the usage of the AbstractTransactionalSpringContextTests ... works like a treat!

          Comment


          • #6
            IllegalAccessException

            I have not been able to make AbstractTransactionalSpringContextTests to work. It gave me a java.lang.IllegalAccessException: Class org.springframework.test.AbstractDependencyInjecti onSpringContextTests can not access a member of class my.package.SpringTestCase with modifiers "protected".

            I created my.package.SpringTestCase as a subclass of AbstractTransactionalSpringContextTests, to serve as a common superclass for my testcases, and added a protected field to hold a reference to a Dao.

            I called 'setPopulateProtectedVariables(true);' in the constructor.

            Did I miss anything?

            Comment


            • #7
              Hi Eric Jan!

              I think there may have been a bug in AbstractDependencyInjectionSpringContext tests, where it was not calling setAccessible(true) on the protected field. I've just changed it. (Too late for 1.1.3, however--you'll need to pull the latest version from CVS.)

              Personally, I tend to populate the tests using Setter Injection, rather than the protected field approach.

              I've also improved the Javadoc.

              Rgds
              Rod

              Comment


              • #8
                Hi Rod!

                The reason I tried to use field injection was that my class has a property for the type of which there were three beans in my context: one of the exact type, and two of different subtypes. I got the setter injection to work by breaking up the class hierarchy, which was not useful anyway.

                The "rollback in the tearDown"-trick speeds up the tests a lot. However, I am not sure about for what kind of tests to use it, after I saw the behaviour of some of my tests change.

                For example, I think I could safely use it in my Dao Unit Tests, disregarding the remark in the Javadoc for AbstractDependencyInjectionSpringContextTests, that it should be used only for integration testing.

                But I have doubts for using it in the tests for the business methods. Each of these methods is configured, by Spring AOP, to run in its own transaction. When two or more calls are in an enclosing transaction, like when using the AbstractTransactionalDataSourceSpringContextTests, they run inside the same Hibernate session too, and the results are sometimes different. Also, when the retrieved objects are inspected in the tests, they are still in the Hibernate session, and behave differently than when they would not be in a Hibernate session.

                And then we run these same tests again remotely, through a facade of stateless session EJB's. The results could be still different, because the method calls would be in the same transaction but not in the same Hibernate session. And the retrieved objects would be outside the Hibernate session when inspected in the tests.

                For what kind of tests would you use these classes, and for what kind not?

                Comment


                • #9
                  ...I think there may have been a bug in AbstractDependencyInjectionSpringContext tests ...
                  I'm trying to create my test class extending it from the AbstractTransactionalSpringContextTests.

                  I'm getting the error message in Eclipse as below:

                  Implicit super constructor AbstractTransactionalSpringContextTests() is undefined for default constructor.
                  Must define an explicit constructor.


                  When I added explicit constructor to AbstractDependencyInjectionSpringContext class, the error is disappeared...
                  So, is it a bug or feature?:shock:

                  Please advise.

                  Comment

                  Working...
                  X