Avoid repeated attempts to load a failing `ApplicationContext` in the TestContext framework [SPR-9548]

[spring-projects-issues]

Mukarram Baig opened SPR-9548 and commented

Lets say I have a test class called ServiceTest with three test methods test1, test2, and test3. All three methods use some resources which are provided by Spring. In the current state of affairs, if there is a problem with the loading of the spring context, the context load is retried for each test method.

Is there a way that I can have it aborted on the first failure itself with existing hook-ins?

There might be good reasons behind it - but I fail to appreciate it. Any pointers would be helpful.

The real problem is that the context load takes a few minutes, and it is useless to keep reattempting to load the context if it has already failed for the first time and only seeks to prolong the time that the CI server takes to report failures.

I was thinking of having an attemptMap in ContextCache that the TestContext modifies when it encounters a failed ApplicationContext. A repeated load will be (on an opt-in flag set) disallowed via an exception. I have attached a rudimentary patch to indicate what I meant. Sorry that I haven't tested it (don't have gradle installed or an IDE plugin that can do it for me - am still a maven boy :))

---

Affects: 3.1 GA

Reference URL: http://stackoverflow.com/questions/11202535/ability-to-avoid-repeated-load-of-application-context-in-spring-testcontext-via

Attachments:

• spring-test.patch (3.72 kB)

6 votes, 8 watchers

[spring-projects-issues]

muhamadto commented

Is there any update on when this enhancement might be added?

[spring-projects-issues]

Michael Tecourt commented

This feature would really speed up feedback of failing integration tests on a complete Spring (Boot) application.
CI builds last a long time looping desperately on a test context that will never load due to a bad configuration.
And if you have tests for every use case, the longer the wait.

We also let Spring start embedded databases or TestContainers rather than JUnit rules because the same context is reused for all test classes, when a JUnit class rule is reloaded for each test class.
When the context crashes though, we end up looping on costly database startups/shutdowns.

[spring-projects-issues]

Sam Brannen commented

I've moved this to the 5.x Backlog in order to look into this in the 5.x time frame.

[sbrannen]

Related discussion on Stack Overflow.