Top level @TestConfiguration classes should be picked up by SpringBootTest

[plamentotev]

Hi,

I'm using Spring Boot 1.4.0 with spring-boot-starter-web and spring-boot-starter-test starters. I would like to be able to configure additional beans that should be available only to test classes. But using top-level @TestConfiguration does not work - I expected that this way the test configuration should be shared by all test classes, but in fact it's just ignored.

The other way to share @TestConfiguration classes - that is to define a static inner-class @TestConfiguration inside base class, does not work either. The classes that extend the base class does not pick the inner @TestConfiguration class. I think this would be nice addition - this way you can share the same test configuration between a group of test classes that share the same base class - for example I have base class for all integration tests. This way I could add additional configuration that is only applied to the integration testes.

[snicoll]

This is the documentation for @TestConfiguration

If you want to customize the primary configuration, you can use a nested @TestConfiguration class. Unlike a nested @configuration class which would be used instead of a your application’s primary configuration, a nested @TestConfiguration class will be used in addition to your application’s primary configuration.

It's clearly stated that you can't use that with top-level class. What's wrong with @Import(YourConfiguration.class)?

Can you show what the base class and sub-class looks like (in particular which test annotations are present on them?

[plamentotev]

Can you show what the base class and sub-class looks like (in particular which test annotations are present on them?

Sure. Here are the two classes.

What's wrong with @Import(YourConfiguration.class)?

Nothing wrong actually. It's just that in my opinion marking a top level class with @TestConfiguration is more convenient way to share configuration between all test classes. And feels natural - inner class adds to the configuration for this particular class, and top level class adds to the configuration of all test classes. Of course one may argue this is not good practice as usually the test classes should be independent (one test class should not affect the execution of another test class) and such shared configuration may violate this if not used properly.

It's clearly stated that you can't use that with top-level class.

That part is clear, but whats is not perfectly clear is what is written a paragraph later:

@TestComponent and @TestConfiguration are only needed on top level classes. If you define @Configuration or @Component as inner-classes within a test, they will be automatically filtered.

So what's the purpose of such classes then? To be used with @Import and not picked up by the scanning by mistake?

Anyway this is more of a proposal for enhancement. As you pointed out, it is indeed documented that @TestConfiguration should be used with inner classes.

[philwebb]

I think it might be a little confusing to have @TestConfiguration behave differently depending on if it is a top-level class for not. I'd rather introduce an attribute that explicitly defines when the configuration is loaded. Something like:

@TestConfiguration(excludeFromScan=false)

[snicoll]

How about disabling it when it's a top-level class? That way, there's only one semantic and the name fits quite well.

[plamentotev]

How about disabling it when it's a top-level class? That way, there's only one semantic and the name fits quite well.

@snicoll do you mean the current behavior? Unless you mean something else please feel free to close this. Looks like I misunderstood how @Configuration and @TestConfiguration work. Sorry about that 😄

I think it might be a little confusing to have @TestConfiguration behave differently depending on if it is a top-level class for not.

It is indeed a little confusing. To admit I was a bit confused what is the difference between nested @TestConfiguration and top-level @TestConfiguration. Well after I read the documentation more carefully and after this discussion (@snicoll thanks for pointing to @import, that really helped) I think now everything is clear. But it's not so obvious when you read it for the first time. But of course it could be just me.

[Roy-Lu]

Hi @plamentotev, I'm also confused with the document. And I don't know how to solve my problem neither. My situation is, there's a configuration and I want to replace it with another configuration during testing. I don't know how to do it.

[jhyot]

I came here because I was looking whether there was an open bug for @TestConfiguration or whether I misunderstood how it is supposed to behave when it's a top-level class.

In my opinion the documentation is slightly confusing (see 3 people in this issue who misunderstood it).
I think it should be explicitly noted in http://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#boot-features-testing-spring-boot-applications-excluding-config that top-level @TestConfiguration/@TestComponent will neither be picked up by @SpringBootApplication scanning, nor by @SpringBootTest scanning, and are instead intended to be used with @Import.

[jkuipers]

A +1 from me on the confusing documentation (which also led me to discover this issue). Especially the wording "@TestComponent and @TestConfiguration are only needed on top level classes." following right after the statement "you can use a nested @TestConfiguration class" left me utterly confused about its purpose. "are only needed" to me suggests that you would never use them on inner classes, which seems wrong.
IIUC the behavior really is "when used as a replacement for @configuration on a nested (static) class, it prevents that class from replacing the primary configuration, becoming additive instead" and "when used as a replacement for @configuration on a top level class, it prevents that class from being component-scanned, requiring it to be @Import-ed explicitly instead".

[wilkinsona]

@jkuipers I assume you meant @Configuration rather than @Component above? Other than that, I think that's an accurate description of the behaviour. I think we should update the docs accordingly.

[jkuipers]

Oops: that's indeed what I intended to say. I'll update my former comment. Thanks for confirming that at least my understanding is correct now.

[snicoll]

Actually, this became a duplicate of #8421

[hantsy]

My @TestConfiguration is nested in the test class, all single tests are run successfully if ran them one by one, but I encountered failure when ran the test class directly, https://stackoverflow.com/questions/48483643/confused-with-spring-boot-test-specific-testconfiguration.

[snicoll]

@hantsy this issue is closed and we don't use the tracker for questions.