Hello! I am really sorry for that repeated post and I don't want to spam but I feel that we have misunderstanding. And it is a better process if you explain why it is not a bug when you close the issue.

Previous issues are:

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

Let me share some context first. Maybe it will help us to overcome misundestanding: I try to apply this advise of @sbrannen. AFAIK this person is quite famous Spring contributor so I can trust him. https://stackoverflow.com/questions/50607285/spring-boot-testconfiguration-not-overriding-bean-during-integration-test/50643036#50643036

I've prepared MRE of my issue here(please notice that branch is bug/config_issue): https://github.com/gredwhite/springboottestconfigissue_demo/blob/bug/config_issue

Looks like I fully follow the advise from @sbrannen answer. But when I start test https://github.com/gredwhite/springboottestconfigissue_demo/blob/bug/config_issue/src/test/kotlin/com/example/demo/DemoControllerTest.kt

I see the spring context load issue because the test loads production bean declared in MyConfiguration although my aim is replacing(!!!) the bean declared inside that class for particular test using bean declared inside class marked with @TestConfiguration annotation and using reference to that class in @Import annotation which is put above the Test

Comment From: philwebb

@gredwhite Please stop opening duplicate issues. As I already mentioned this isn't a bug and it doesn't belong in the issue tracker. I have added another comment to the question on stackoverflow.com.

And it is a better process if you explain why it is not a bug when you close the issue

Running an open source project is time consuming and we do our best with the limited resources that we have. We simply can't explain every detail for all issues that are raised and we rely on our community to help fill in the gaps at stackoverflow.com. I think the fundamental problem here is that you've assumed @TestConfiguration is designed replace @Configuration in your main code, and that's simply not the case.

You could argue that being able replace production @Configuration classes with test @Configuration classes would be a worthwhile feature, but that's an argument that still doesn't belong in this issue tracker. @Configuration class processing is handled by Spring Framework so you would need to make that case in their issue tracker.