Announcement Announcement Module
No announcement yet.
Overriding beans for testing Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Overriding beans for testing

    Hi. I am trying to set up an integration test, so I want to load all of my contexts. One of them is for a DataSource and uses the JndiObjectFactoryBean. If I try to load this in a JUnit test, I get an error about not specifying a class name for the InitialContext.

    <bean id="dataSource" class="org.springframework.jndi.JndiObjectFactoryBean">
       <property name="jndiName" value="jdbc/DATASOURCE"/>
    I would like to set up a testing-context.xml that can override the definition of dataSource to use a DriverManagerDataSource:

    <bean id="dataSource" class="org.springframework.jdbc.datasource.DriverManagerDataSource">
       <property name="driverClassName" value="oracle.jdbc.driver.OracleDriver"/>
    If I could get the production context to load, then I could load the testing context and supply the production context as a parent and it would work fine, but of course, I cannot get the production context to load.

    How can I override this one definition? Should I move the single definition into its own file, then create a testing-context.xml. This way I could load the production-context.xml in production and the testing-context.xml in testing. I do not really like this idea because there could be more definitions I want to override. I like the organization I currently have and I do not want to move the dataSource definition out of the logically grouped context I have. If I later need to override some of the email settings (which I foresee), I do not want to pull a server defintion out of the email-context.xml and into a production-context.xml. I would prefer to keep those definitions logically grouped.

    Thanks for any help


  • #2
    Yeah, its tricky

    I bite the bullet and move the environment related beans into seperate files and load them off the classpath. You can also do the same thing with propertyPlaceHolder and system properties.

    This isn't really roo much of a problem because the majority (99%) of my unit tests are just testing POJOs and mocks.