@TestConfiguration clashing with non-test config

[RobMaskell]

I'm trying to have different config for running a spring boot 1.5.3 app in STS (and eventually prod) but have different config for tests.

I read this in the docs

When placed on a top-level class, @TestConfiguration indicates that classes in src/test/java should not be picked up by scanning. You can then import that class explicitly where it is required:

Problem is that I'm getting the test config when I start the app from the STS dashboard.

Sample app here, try to start it and it complains about two beans when it wanted only one. Same behavior in 1.4.3 makes me think this must be by design so what did I do wrong?

***************************
APPLICATION FAILED TO START
***************************

Description:

Field someService in com.example.TestController required a single bean, but 2 were found:
	- getSomeTestService: defined by method 'getSomeTestService' in class path resource [com/example/TestConfig.class]
	- getSomeService: defined by method 'getSomeService' in com.example.TestconfigApplication

Thanks

[panatl]

I can't reproduce this. Any chance you can provide me your sample code?
Thanks

[wilkinsona]

@panatl There is a link to a sample in the issue's description

[wilkinsona]

@RobMaskell I suspect the problem is that whatever Gradle support you're using doesn't separate the main and test class paths. This is one area where Maven is better than Gradle as m2e does make that separation. Can you please describe how you're importing your Gradle project into STS and let us know which version of STS you're using?

[RobMaskell]

Thanks for the swift response, STS version is 3.8.4 and the gradle support is Buildship 1.0.21, I think there is a Buildship 2 I'll see if I can upgrade and test

[RobMaskell]

Upgraded to buildship 2.0.2 same issue when starting the app from the STS dashboard

[RobMaskell]

@wilkinsona your suspicion was correct tried it in an equiv maven project and works as advertised in docs.

Should I report this to the buildship guys, or are they going to say Spring problem?

[RobMaskell]

Thinking about this a bit more the docs suggest that @TestConfiguration is not picked up by scanning, in which case should it matter whether or not it is on the classpath?

[snicoll]

Don't you have a custom @ComponentScan directive somewhere?

[RobMaskell]

@snicoll haven't needed to thus far what is provided by @SpringBootApplication has been sufficient and it looked as if @TestConfiguration would solve the prod vs test config issues. Is @ComponentScan your suggested workaround / fix?