Announcement Announcement Module

JavaConfig forum decommissioned in favor of Core Container

As described at

key features of the Spring JavaConfig project have been migrated into the core Spring Framework as of version 3.0.

Please see the Spring 3.0 documentation on @Configuration and @Bean support:

For any questions related to @Configuration classes and @Bean methods in Spring 3.0, please post in the dedicated 'Core Container' forum at
See more
See less
How to reload the application context with each junit test? Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • How to reload the application context with each junit test?

    According to the 2.5.x documentation the ApplicationContext is cached and reused by each test and not reloaded. I know I can annotate the test with DirtiesContext but how can I change the default so that the context is reloaded for each test without annotating each test or setting isDirty()?

    I tried DirtiesContext in Before or After methods but this doesn't work so I'm looking for an alternative technique.

    I don't mind the time wasted reloading each context as its fast enough for me and I need a clean state before each test otherwise tests fail.

    I'm using Java Config M4, junit 4.4, core 2.5.6, test 2.5.6 and dependency injection for all my fixtures with annotations on private fields (which is very nice by the way as it removes a lot of setters from the public interface). I'm not using a database and only have pojos in my context.


  • #2

    Currently you must annotate each test method with @DirtiesContext to force a reload of the ApplicationContext. Consider adding a new JIRA issue if you'd like a way to set a default for a given test that assumes all test methods dirty the context.


    • #3
      I have a solution (attached) which uses an annotation (@DirtiesClassContext) at the class level which does what I want and forces each test to reload its context. I felt it was better than a more global default.


      • #4

        Sounds useful. Consider adding a new JIRA issue for this (New Feature) and attach the zip there. This will get developer attention more effectively.

        - C


        • #5
          see SPR-5640