Support for bean instances located in test sources for @ApplicationModuleTest
#202
Comments
odrotbohm
changed the title
|
@odrotbohm I tried includind a @ApplicationModuleTest
@AutoConfigureWebTestClient
class HabitControllerIntegrationTest {
@Autowired private lateinit var webTestClient: WebTestClient
@Test
fun `should return habits`() {
webTestClient.get().uri("/habits")
.exchange()
.expectStatus().isOk()
.expectBody<List<Habit>>()
.value { assertThat(it).hasSize(1) }
}
}Test execution fails with I this a related issue, unrelated issue or am I doing something wrong entirely? |
|
It looks like the Am I assuming right, that the working alternative is not a plain |
|
Thank you for pointing me to the I totally agree with you that it should™ only work with if (springBootTest.webEnvironment().isEmbedded()) {
registerWebTeslient(context);
}I am not sure why the test works, but it does. Is there something else besides the Also: I guess you won't be able to fix the compatiblity with EDIT: This is the code path used when using plain |
|
Wait a second, you're using Is there any chance you can put together a simple (Java/Maven) example project that shows the injection fail using |
|
Wow you are fast. 😄 ❤️ As luck would have it, I set up a sample project today anyways to evaluate Spring Modulith for us. Oh sorry, it uses Kotlin/Gradle, I hope that's okay. Let me know if you need a Java/Maven sample as well. |
|
If you don't mind, I'd really appreciate a Java/Maven version as I then don't have to fight those and IDEA to get the stuff debugged. 😬 |
|
Well I guess this explains why the Spring Modulith reference is Java/Maven only, considering almost all Spring references have documentation samples for Kotlin and Gradle as well. 😄 But no worries, here you go: https://github.com/denniseffing/spring-modulith-test-java |
|
Thanks for that. The difference is the presence of a I think I'll have to give it some thought, but as it looks right now, we should be able to simply meta-annotate |
…tTest. @ApplicationModuleTest is now meta-annotated with @SpringBootTest. This allows us to remove a couple of declarations that we actually had copied from it (such as the TestContextBootstrapper, the SpringExtension etc.) The presence of the original annotation allow test-related auto-configuration to inspect @SprignBootTest for particular configuration. For example, we now alias the WebEnvironment to make it configurable for the test execution.
|
I've filed and fixed #253 to make sure standard, test related auto-configuration can read configuration of the |
|
Thank you for the fast fix! |
|
@denniseffing – I've also created #255 and #256 to track the extension of the documentation for Gradle and Kotlin. |
|
I read through this discussion but either I missed the solution of the topic or it is not there. Currently, I am working on a small Spring Modulith project and I just found out that @ApplicationModuleTest annotation does not import test beans to the spring context. Is there any other solution to this apart from doing it manually with @componentscan for example? |
|
@KarasDominik – Can you elaborate what “… Do you have a reproducer handy that shows behavior you consider erroneous? |
|
@odrotbohm I have exactly the same problem as described here: #201 (or in the first post of this issue). I have some module which contains some beans and when I try to test this module I need an additional bean (which is defined only in tests, not production code). As a result, when try to autowire this bean into my test and run it I get the following error: |
|
It's hard to assess without a reproducer. Are you sure the type of that test bean is located in any of the packages scanned during the test execution? |
|
Here is some sample repo: https://github.com/KarasDominik/QuickCart/ |
|
Lovely, I'll have a look ASAP. |
|
I found the root of the problem. We hook into the component scanning in a way that checks whether scanned classes are contained in the packages we selected for bootstrap. That contains check inspects the actual classes in that package based on the ArchUnit import of types. That in turn only sees classes from the production classpath. This is why any code from the test sources is excluded and the bootstrap fails. I guess we need to switch to a name comparison for this particular use case as at this point, we're only interested whether a type is logically located in the package, not necessarily physically located in the package we ArchUnit-scanned. |
|
Thanks for breaking it down! I am not gonna lie, I am new to spring modulith and I am not sure if the solution you explained is available within the library? |
|
Nope, I need to fix it. I just wanted to give you a heads up. |
…cationModuleTest. Prior to this commit, the TypeExcludeFilter registered by @ApplicationModuleTest decided whether to include a type based on the ApplicationModules instance and the content of the modules' backing JavaPackage instances. Those in turn always consider the classes scanned by ArchUnit to decide whether they include a type or not. As an ApplicationModules instance is set up to only consider production code, any type located in the test sources was disregarded from component scanning. The checks for package inclusion for a test execution have now been revamped to consider the sole package names when filtering types for inclusion.
|
This should be in place. Would you mind giving the 1.4 snapshots a try? |
odrotbohm
changed the title
@ApplicationModuleTest
|
Thanks for taking care of it. Sorry, but how do I access 1.4.0-M3 version? On Spring Milestones I see only 1.4.0-M2 and this version does not solve the issue |
|
M3 is due this Friday. Meanwhile, please use |
Discussed in #201
Originally posted by genuss May 3, 2023
First of all, thank you for a great project. I just started to dig in and it looks very promising!
Currently I'm trying to arrange some module tests and faced up an issue which I can't solve now. To be more clear in what I'm going to explain now I created an example project.
The project consists of two modules:
firstandsecondwhich don't do anything as it's not important now.What I'm trying to achieve is to create some FirstModuleTestHelper which acts as some text fixture and is used by autowiring it in test-classes or other fixtures. This has always worked and works now with @SpringBootTest but it doesn't work with @ApplicationModuleTest and fails with this exception:
I tried to debug this, but being unfamiliar with code, didn't have any luck. Looks like it's somehow connected to archunit's
ImportOptionbut I'm not sure.Anyway, what do you think about extending module test context to take into account such beans?
The text was updated successfully, but these errors were encountered: