Avoid repeated attempts to load 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.

[sbrannen]

Related Issues:

• https://github.com/spring-projects/spring-boot/issues/24888

[dreis2211]

Any progress on this would be highly appreciated as it unnecessarily prolongs build times and is hurting effectivity quite badly... Gradle users might get away with configuring

test {
   failFast = true
}

But that is not the same thing as it just stops after the first test vs. executing all tests (but doing this in a fast way if we know the context won't start)

[HzjNeverStop]

Is there any progress on this issue? Will it be implemented in spring framework 6.1？

[snicoll]

@sbrannen is there a reason this issue is moved from one milestone to the next? (see history). I think we've decided to use x Backlog for this.

[sbrannen]

I think we've decided to use x Backlog for this.

I moved it to 6.0.x last October: https://github.com/spring-projects/spring-framework/issues/14182#event-7555188932.

[sbrannen]

Update: current work on this feature can be viewed in the following feature branch.

https://github.com/spring-projects/spring-framework/compare/main...sbrannen:spring-framework:issues/gh-14182-TCF-context-load-failure-threshold

[sbrannen]

If you've voted for this issue, you'll be happy to know that...

Spring Framework 6.1 will finally have "test context failure threshold" support! 🍃 🥳

It's been a long time coming, but you can now rest assured that your test suite won't take forever due to failing ApplicationContext configuration.

For details, check out the documentation and the related commit.