Provide option in MockRestServiceServer where an instance of MockMvc is used to obtain the response [SPR-9917] #14550
Comments
|
Jeff Holmes commented Just to provide a little background motivation, I had implemented an integration test using RestTemplate on client side to invoke MVC controller, and used an embedded servlet (winstone, or jetty would do) to run MVC controller. With this feature, it would be possible to avoid use of a servlet container, separate threads, network communication, and still test post conditions after client side and server side code executes (in my case I set up an embedded db that's updated by both client and server). |
|
Rossen Stoyanchev commented I've added a |
|
Jeff Holmes commented Rossen, very nice. I was able to get this to work in my scenario, which was using xml config and profiles (took a bit of extra code to get profiles to be recognized within Controller context). Very satisfying to get rid of embedded servlet container :) |
|
Rossen Stoyanchev commented Jeff Holmes, thanks for confirming this. Can you elaborate on the issue with the profiles? In other words I would expect this to work: @RunWith(SpringJUnit4ClassRunner.class)
@WebAppConfiguration
@ContextConfiguration("com/vmware/vfra/batch/web/servlet-context.xml")
@ActiveProfiles(profiles = {"dev", "property-datasource"})
public class SuccessfulStepTest {
@Autowired
private WebApplicationContext wac;
@Autowired
private RestStepExecutionService restStepExecutionService;
...
@Before
public void setup() {
MockMvc mockMvc = MockMvcBuilders.webAppContextSetup(this.wac)
.alwaysExpect(status().isAccepted()).build();
RestTemplate restTemplate = new RestTemplate(
new MockMvcClientHttpRequestFactory(mockMvc));
// used by MasterPartitionHandler
restStepExecutionService.setRestTemplate(restTemplate);
restStepExecutionService.setRestUrl("/job/{jobExecutionId}/step/{stepId}/name/{stepName}");
}
...
}The reason it is important is because when the TestContext framework loads the Spring configuration, it caches. Otherwise it's reloaded before every test. /cc Sam Brannen |
|
Jeff Holmes commented If I removed the line that set the profile on the Environment, the web application context wouldn't recognize that active profiles were set and would fail to load a number of beans that were defined under the 'property-datasoruce' profile. In the stack below, the jobDataSource bean is defined under the property-datasource profile. org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'jobRepository': Cannot resolve reference to bean 'jobDataSource' while setting bean property 'dataSource'; nested exception is org.springframework.beans.factory.NoSuchBeanDefinitionException: No bean named 'jobDataSource' is defined |
|
Rossen Stoyanchev commented The stack trace shows you still have the code from your example that instantiates a WebApplicationContext. If you look at my example you will see that the Spring configuration is loaded through |
|
Sam Brannen commented FYI: Rossen's example is missing a preceding slash for the classpath resource for the XML config file. It should look like this: @RunWith(SpringJUnit4ClassRunner.class)
@WebAppConfiguration
@ContextConfiguration("/com/vmware/vfra/batch/web/servlet-context.xml")
@ActiveProfiles({"dev", "property-datasource"})
public class SuccessfulStepTest {
@Autowired
private WebApplicationContext wac;
// ...
}- Sam |
|
Jeff Holmes commented Cool, I got it to work as you described... SuccessfulStepTest-context.xml: ...
<import resource="classpath:/com/vmware/vfra/batch/web/servlet-context.xml" />
... |
|
Sam Brannen commented Jeff, We're glad to hear that works for you. And thanks for providing us the feedback! |
spring-projects-issues
added
in: test
Rossen Stoyanchev opened SPR-9917 and commented
Currently
MockRestServiceServerallows defining expected requests and the stub response that should be returned for each expected request.In some cases, where tests involve both client- and server-side code, it would be useful if instead of defining stub responses, the responses were obtained by invoking the server-side Spring MVC Test support (i.e. an instance of MockMvc) to obtain a MockHttpServletResponse and adapt it to a client-side response. This would enable tests that span both client and server side code.
This is based on question raised by Jeff Holmes in presentation at SpringOne.
Affects: 3.2 M2
1 votes, 3 watchers
The text was updated successfully, but these errors were encountered: