@@ -5398,11 +5398,12 @@ The search algorithm works up from the package that contains the test until it f
5398
5398
<<using-boot-structuring-your-code, structured your code>> in a sensible way your main
5399
5399
configuration is usually found.
5400
5400
5401
- NOTE: If you use a <<boot-features-testing-spring-boot-applications-testing-autoconfigured-tests,
5402
- test annotation to test a more specific slice of your application>> with such setup, any
5403
- user configuration defined on your `@SpringBootApplication` will be processed. This can
5404
- break the purpose of slicing and it is recommended to move such configuration to a
5405
- `@Configuration` class alongside your `@SpringBootApplication`.
5401
+ NOTE: If you use a
5402
+ <<boot-features-testing-spring-boot-applications-testing-autoconfigured-tests, test
5403
+ annotation to test a more specific slice of your application>> with such setup, you should
5404
+ avoid adding configuration that are specific to a particular area on the
5405
+ <<boot-features-testing-spring-boot-applications-testing-user-configuration, main's
5406
+ application class>>.
5406
5407
5407
5408
If you want to customize the primary configuration, you can use a nested
5408
5409
`@TestConfiguration` class. Unlike a nested `@Configuration` class which would be used
@@ -6012,6 +6013,66 @@ automatically generate the default snippets:
6012
6013
6013
6014
6014
6015
6016
+ [[boot-features-testing-spring-boot-applications-testing-user-configuration]]
6017
+ ==== User configuration and slicing
6018
+ If you've <<using-boot-structuring-your-code, structured your code>> in a sensible way,
6019
+ your `@SpringBootApplication` class is
6020
+ <<boot-features-testing-spring-boot-applications-detecting-config, used by default>> as
6021
+ the configuration of your tests.
6022
+
6023
+ It then becomes important not to litter the application's main class with configuration
6024
+ that are are specific to a particular area of its functionality.
6025
+
6026
+ Let's assume that you are using Spring Batch and you're relying on the auto-configuration
6027
+ for it. Your could define your `@SpringBootApplication` as follows:
6028
+
6029
+ [source,java,indent=0]
6030
+ ----
6031
+ @SpringBootApplication
6032
+ @EnableBatchProcessing
6033
+ public class SampleApplication { ... }
6034
+ ----
6035
+
6036
+ Because this class is the source configuration for the test, any slice test will actually
6037
+ attempt to start Spring Batch, which is definitely now what you want to do. A recommended
6038
+ approach is to move that area-specific configuration to a separate `@Configuration`
6039
+ class at the same level as your application.
6040
+
6041
+ [source,java,indent=0]
6042
+ ----
6043
+ @Configuration
6044
+ @EnableBatchProcessing
6045
+ public class BatchConfiguration { ... }
6046
+ ----
6047
+
6048
+ NOTE: Depending on the surface area of your application, you may either have a single
6049
+ `ApplicationConfiguration` class for your customizations or one class per domain area
6050
+ when it makes sense. The latter approach allows you to enable it in one of your test
6051
+ if necessary via `@Import`.
6052
+
6053
+ Another source of confusion is classpath scanning. Let's assume that, while you've
6054
+ structured your code in a sensible way, you need to scan an additional package. Your
6055
+ application may look like this:
6056
+
6057
+ [source,java,indent=0]
6058
+ ----
6059
+ @SpringBootApplication
6060
+ @ComponentScan({ "com.example.app", "org.acme.another" })
6061
+ public class SampleApplication { ... }
6062
+ ----
6063
+
6064
+ This effectively overrides the default component scan directive with the side effect of
6065
+ scanning those two packages regardless of the slice that you've chosen. For instance a
6066
+ `@DataJpaTest` will all the sudden scan components and user configurations of your
6067
+ application. Again, moving the custom directive to a separate class is a good way to fix
6068
+ this issue.
6069
+
6070
+ TIP: If this is not an option for you, you can create a `@SpringBootConfiguration`
6071
+ somewhere in the hierarchy of your test so that it is used instead. Or you can specify
6072
+ a source for your test which will disable the behaviour of finding a default one.
6073
+
6074
+
6075
+
6015
6076
[[boot-features-testing-spring-boot-applications-with-spock]]
6016
6077
==== Using Spock to test Spring Boot applications
6017
6078
If you wish to use Spock to test a Spring Boot application you should add a dependency
0 commit comments