ApplicationContext fails to load in TestNG test if previous test is annotated with @DirtiesContext [SPR-12918] #17517
Comments
|
Sam Brannen commented I'm afraid the supplied stack trace does not provide much to go on, other than the fact that you are using TestNG. Can you please provide the details of your setup? Are tests #1 and #2 different test classes or different test methods within the same class? Have you tried a different version of Spring, for example 4.1.0? Where is Exactly which Thanks for any feedback you can provide! Sam |
|
Sam Brannen commented In any case, without knowing the details of your configuration, it sounds like you might be closing the The reason I suspect this is that a See my comments here for details. Of course, I cannot verify this assumption without seeing your test code. So please confirm whether you are closing the context programmatically. Thanks, Sam |
|
David Blake commented The Test #1 and test #2 are different test classes in separate source files. Test class #1 is annotated with I am not explicitly closing the ApplicationContext programmaticall, just using |
|
David Blake commented I can try going back from 4.1.6 until I see which version the issue came in on if that is helpful. I will try the 4.1.0 you suggested first. |
|
Sam Brannen commented OK. Thanks for the feedback. I'll see if I can reproduce the issue. In the meantime, if you could answer my question above regarding |
|
David Blake commented Thanks for your assistance Sam. I will get you the requested information.. |
|
Sam Brannen commented This is potentially related to #15172, #17012, and INT-3543. |
|
David Blake commented I don't have any AbstractTestNGSpringContextTests@TestExecutionListeners({
ServletTestExecutionListener.class,
DependencyInjectionTestExecutionListener.class,
DirtiesContextTestExecutionListener.class})
public abstract class AbstractTestNGSpringContextTests implements IHookable, ApplicationContextAware {HPUnitTest Class@ContextConfiguration(classes = ServicesUnitTestConfig.class)
@ActiveProfiles("unit")
public abstract class HPUnitTest extends AbstractTestNGSpringContextTests {Test Class #1@DirtiesContext
@Test(groups = { "L1", "Service Tests", "Queue" })
public class AccountSummaryServiceTest extends HPUnitTest {Test Class #2@Test(groups = { "L1", "Service Tests" })
public class SchedulerServiceTest extends HPUnitTest { |
|
Sam Brannen commented This issue is potentially related to #10800. |
|
Sam Brannen commented Out of curiosity, what happens if you configure your three test classes as follows? HPUnitTest Class@ContextConfiguration(classes = ServicesUnitTestConfig.class)
@ActiveProfiles("unit")
public abstract class HPUnitTest extends AbstractTestNGSpringContextTests {Test Class #1@DirtiesContext
@Test(suiteName = "AccountSummaryService", groups = {"L1", "Service Tests", "Queue"})
public class AccountSummaryServiceTest extends HPUnitTest {Test Class #2@Test(suiteName = "SchedulerService", groups = {"L1", "Service Tests"})
public class SchedulerServiceTest extends HPUnitTest {Note the use of unique values for Please let me know the outcome of your tests with the above configuration. Cheers, Sam |
|
David Blake commented Tried the suggested changes and it failed the same way. |
|
David Blake commented Rebuilt with 4.1.0 and it fails with a similar call stack though the 4.1.6 call stack has extra details logged so it looks like the trace logging was improved over time. Overall it is the same illegalStateException - Failed to load ApplicationContext error. |
|
Sam Brannen commented Thanks for helping investigate. Since those attempts failed as well, I think this issue may not be directly related to |
|
David Blake commented Based on what we've seen so far with testing this, I'm curious what changes have happened in org.springframework.beans.factory between 4.0.5 and 4.1.0. I'm currently stepping through the working code with 4.0.5 to try and better understand what makes that work for my case. I'll also try going back to 4.1.0 and do the same there for the failing case. I'll post what I find if anything. |
|
David Blake commented Here is what I'm seeing as a difference between the working 4.0.5 case and the 4.1.0 failing case. In the stack trace in this issue's Description, notice the call to the method Non-working 4.1+ caseStepping into the call stack results in going into Spring's Working 4.0.5 caseStepping into the call stack does not go into Spring's SummaryIt appears that 4.0.5 to 4.1+ introduces extra processing or at least different processing for |
|
Sam Brannen commented Thank you for taking the time to perform additional analysis! We will take your findings into account. |
|
Sam Brannen commented Interim testing work has been committed in GitHub commit 3c5a9b4:
|
|
Sam Brannen commented This issue is potentially related to #15166, in the sense that parallel construction of an application context results in a |
|
David Blake commented I see that version 4.1.7 is due around May 20th. Do we currently know if a fix for this issue will be possible by that date? |
|
David Blake commented Update to previous comment. Version 4.1.7 has been pushed out to mid July according to the dashboard. I am still interested in a fix for this issue and currently don't have a way to work around this. Let me know if I can help assist with anything. |
|
Juergen Hoeller commented So with 4.0.5, it looks like your Now, with the transaction actually kicking in there, it tries to resolve a transaction manager and apparently encounters an incompletely initialized Juergen |
|
David Blake commented
Yes, if I remove the
There is nothing, I know of, that our code is doing to either close the ApplicationContext or asynchronously access the context. The failure is not happening during a specific Test but instead during what appears to be the initialization of the second Test class in preparation for running the second group of Test. The first Test class has the Does this answer your questions completely? I'd be happy to expand further. |
|
David Blake commented Removing the reference to the bean, Environment, that is the cause of the failure to load the Seems the failure of the Environment has been an issue in the past and is curiously the only bean of around 300 that get loaded in our system that is a problem currently. Just an observation. import org.springframework.core.env.Environment; |
|
Sam Brannen commented
That's odd, because it really sounds like that would be the case based on the error you're encountering.
Again, this sounds to me like there is some overlap in the execution of the tests in terms of test execution lifecycle callbacks. Have you tried out my unique suite name per test class proposal (see comments above) on all of your TestNG-based tests?
Yes, the corresponding
That is correct, but still... it sounds like the ordering is not correct. Could you please execute your tests with See my detailed comments in #10800 for the kind of problems that can occur if the TestNG test execution order is incorrectly configured. Regards, Sam |
|
David Blake commented
One thing further. I can see in the spring tools UI while I'm running the tests that the first test class completes all 8 tests successfully and the call stack shows it going into testing code to initialize the context. During this the beans are reloaded, there are ~300 in my projects, and it always fails trying to lookup the I will 1. turn on debug when I know how. and 2. will further simplify the test run needed to show the failure. thanks for your inputs and assistance. David Blake |
|
Sam Brannen commented To enable If you already have |
|
Sam Brannen commented
Yes, I recall that. ;) This time I was asking if you declared a unique
YES. That would be very beneficial, especially if you can provide us a scaled down project that reproduces the issue. That way we could get our hands on something that is actually breaking and debug it ourselves. Thanks in advance! Sam |
|
David Blake commented Our code base was modified which resulted in the removal of the Now that we are past this we have run into another issue that follows a similar theme in that Spring Framework 4.0.5 works with TestNG and I will submit this as a different defect unless you want it to remain part of this one. |
|
Sam Brannen commented Please note that #19400 may be duplicate of this issue. |
spring-projects-issues
added
status: waiting-for-triage
rstoyanchev
added
status: bulk-closed
|
Bulk closing outdated, unresolved issues. Please, reopen if still relevant. |
David Blake opened SPR-12918 and commented
Upgrading from Spring Framework 4.0.5 to 4.1.6 (or 4.1.0) causes Test class #2 to fail with the following exception if Test class #1 is annotated with
@DirtiesContextat the class level (see example code in the comments section for details).Affects: 4.1 GA
Issue Links:
ApplicationContextcreation in the TestContext framework [SPR-10536] #15166 Do not serialize ApplicationContext creation in the TestContext frameworkReferenced from: commits 3c5a9b4
The text was updated successfully, but these errors were encountered: