30 lines
		
	
	
		
			1.7 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
		
		
			
		
	
	
			30 lines
		
	
	
		
			1.7 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
| 
								 | 
							
								[[mockmvc-server-setup-options]]
							 | 
						||
| 
								 | 
							
								= Setup Options
							 | 
						||
| 
								 | 
							
								
							 | 
						||
| 
								 | 
							
								MockMvc can be setup in one of two ways. One is to point directly to the controllers you
							 | 
						||
| 
								 | 
							
								want to test and programmatically configure Spring MVC infrastructure. The second is to
							 | 
						||
| 
								 | 
							
								point to Spring configuration with Spring MVC and controller infrastructure in it.
							 | 
						||
| 
								 | 
							
								
							 | 
						||
| 
								 | 
							
								Which setup option should you use?
							 | 
						||
| 
								 | 
							
								
							 | 
						||
| 
								 | 
							
								The use of an `ApplicationContext` loads your actual Spring MVC configuration, resulting
							 | 
						||
| 
								 | 
							
								The `WebApplicationContext`-based test loads your actual Spring MVC configuration,
							 | 
						||
| 
								 | 
							
								resulting in a more complete integration test. Since the TestContext framework caches
							 | 
						||
| 
								 | 
							
								the loaded Spring configuration, it helps keep tests running fast, even as you introduce
							 | 
						||
| 
								 | 
							
								more tests in your test suite using the same configuration. Furthermore, you can
							 | 
						||
| 
								 | 
							
								override services used by your controller using `@MockitoBean` to remain focused on
							 | 
						||
| 
								 | 
							
								testing the web layer.
							 | 
						||
| 
								 | 
							
								
							 | 
						||
| 
								 | 
							
								The standalone test, on the other hand, is a little closer to a unit test. It tests one
							 | 
						||
| 
								 | 
							
								controller at a time. You can manually inject the controller with mock dependencies, and
							 | 
						||
| 
								 | 
							
								it does not involve loading Spring configuration. Such tests are more focused on style
							 | 
						||
| 
								 | 
							
								and make it easier to see which controller is being tested, whether any specific Spring
							 | 
						||
| 
								 | 
							
								MVC configuration is required to work, and so on. The standalone setup is also a very
							 | 
						||
| 
								 | 
							
								convenient way to write ad-hoc tests to verify specific behavior or to debug an issue.
							 | 
						||
| 
								 | 
							
								
							 | 
						||
| 
								 | 
							
								As with most "`integration versus unit testing`" debates, there is no right or wrong
							 | 
						||
| 
								 | 
							
								answer. However, using standalone tests does imply the need for additional integration
							 | 
						||
| 
								 | 
							
								tests to verify your Spring MVC configuration. Alternatively, you can write all your
							 | 
						||
| 
								 | 
							
								tests with a `WebApplicationContext`, so that they always test against your actual Spring
							 | 
						||
| 
								 | 
							
								MVC configuration.
							 |