Announcement Announcement Module
No announcement yet.
Spring Test Proxies Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Spring Test Proxies

    Hi All,

    I've been using many different portions of Spring throughout my career, but the behavior I'm seeing in one of my Spring Tests is just driving me nuts.

    Let's say I have a Repository that I am trying to test:

    public class CommentsDAO implements ICommentsDAO {

    * The JPA Entity Manager
    private EntityManager em;


    with Spring Test file:

    <?xml version="1.0" encoding="UTF-8"?>
    <beans xmlns=""

    <!-- Annotation Driven Transactions -->

    <!-- JPA Transaction Manager -->
    <bean id="transactionManager" class="org.springframework.orm.jpa.JpaTransactionM anager">
    <property name="entityManagerFactory" ref="entityManagerFactory"/>

    <bean id="entityManagerFactory" class="org.springframework.orm.jpa.LocalEntityMana gerFactoryBean">
    <property name="persistenceUnitName" value="test"/>

    <bean id="commentsArchive" class=""/>

    and Spring/JUnit Test file:

    @ContextConfiguration(locations = {
    @TransactionConfiguration(transactionManager = "transactionManager")
    public class ICommentsDAOTest {

    private CommentsDAO archive;

    I always get errors from Spring that there is no bean of type CommentsDAO. If I switch to the interface type, ICommentsDAO, then everything is happy. It seems that Spring is actually using a dynamic proxy for the bean here instead of just using the bean I have specified.

    Now I thought this may make sense because of the @Transactional I am using here. However, that doesn't work even when I remove all @Transactional and @TransactionConfiguration here.

    Can anyone explain why this is happening? How can I actually just reference the concrete type here instead of the interface type?


    Ronak Patel

  • #2
    Please use [ code][/code ] tags when posting code that way it remains readable.

    Spring creates proxies to do exception handling/exception translation, for that it needs a proxy.


    • #3
      Hi Marten,

      So, is there any particular way I can test the methods for CommentsDAO (which are not already within the ICommentsDAO interface) and still use Spring Test? That doesn't seem like it can be done here.



      • #4
        You should only use springs testing support if you want to do an integration test, if you want to do a unit test then you shouldn't use spring. Which is what you are trying to do at least from my pov. So simply create an instance, mock/stub the dependencies and off you go with your test.

        Or create a special context xml which only contains your class, no annotation-driven stuff and inject the dependencies yourself. But that seems to much work.

        Also we could debate about the fact that you want to test methods inside the CommentsDAO they should be covered by testing your public API. If they aren't then why are those methods there anyway. But that is more of religious debate .


        • #5
          If they aren't then why are those methods there anyway.


          • #6
            I wasn't aware that concrete objects that take in other dependencies via setters to do their job also require the setters/getters to be defined in the Interface.

            If so, that's news to my ears....


            • #7
              Well another debate we can have do you need/want to test your getter/setters... But that is something you can quite easily do without spring isn't it... Simply do injection yourself and see if the same object comes out... There is no need to do that with spring, on the other hand if your setter isn't working the app should blow up when invoking business methods.