Spring-boot: @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?

[snicoll]

@RobMaskell no, a custom @ComponentScan would trigger the problem as it would not register the exclude filter that makes sure @TestConfiguration are ignored.

[snicoll]

That app works fine for me so I must be an IDE configuration issue. Sorry but there is nothing we can do here to help.

[RobMaskell]

@snicoll what IDE did you use to test it maybe I'll just start using that?

[snicoll]

IntelliJ IDEA. I don't get why that class would be picked up all the sudden. Looks a cache issue of some kind to me.

[wilkinsona]

@snicoll I think things have always been that way with Gradle in Eclipse. It works in IntelliJ IDEA as 2016.1 introduced support for each source set being a separate module. There's an open Buildship issue to do something equivalent in Eclipse.

[snicoll]

OK let's conclude here. I got confused by the original report so let's forget about what I wrote with @ComponentScan. Ignoring @TestConfiguration only happens in test so if your IDE doesn't make a difference between test sources and production source you'll have that issue. Nothing Boot specific I am afraid.

Let's follow-up the issue Andy referenced.

[RobMaskell]

@wilkinsona the link to the "open buildship issue" is just linking to jetbrains 2016.1 is here page same as other link, and I can't find the issue on googling?

[wilkinsona]

@RobMaskell I realised I'd used the same link twice shortly after I made the comment and edited it. The second link should be correct now.