Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add overload for MockRestServiceServer.verify with a timeout #22618

Closed
kewne opened this issue Mar 20, 2019 · 4 comments
Closed

Add overload for MockRestServiceServer.verify with a timeout #22618

kewne opened this issue Mar 20, 2019 · 4 comments
Assignees
Labels
in: test Issues in the test module in: web Issues in web modules (web, webmvc, webflux, websocket) type: enhancement A general enhancement
Milestone

Comments

@kewne
Copy link

kewne commented Mar 20, 2019

The goal is to verify that the expected interactions occur up to the given timeout.
This is useful for testing asynchronous flows in event-driven services, similar to the testing support in Spring Amqp.

Sample code:

@SpringBootApplication
public class MyApplication {

  @Autowired
  private RestTemplate template;

  @RabbitListener()
  public void callService(String payload) {
    template.put("http://example.com/hello", payload);
  }
}
@SpringBootTest
@RunWith(SpringRunner.class)
public class ApplicationTest {
  @Autowired
  private MockRestServiceServer mockServer;

  @Autowired
  private AmqpTemplate template;

  @Test
  public void callsService() {
    mockServer.expect(method(PUT))
      .andExpect(requestTo("/hello"))
      .andRespond(withNoContent());
    template.convertAndSend("HelloWorld");
    mockServer.verify(5, TimeUnit.SECONDS);
  }
}
@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged or decided on label Mar 20, 2019
@sbrannen sbrannen added in: test Issues in the test module in: web Issues in web modules (web, webmvc, webflux, websocket) type: enhancement A general enhancement labels Mar 20, 2019
@sbrannen
Copy link
Member

@rstoyanchev, what do you think about adding this?

@rstoyanchev
Copy link
Contributor

How would this work specifically, check if expectations > 0 and if so wait for up to the specified time, but otherwise fail early in case of failures?

@rstoyanchev rstoyanchev added the status: waiting-for-feedback We need additional information before we can continue label Jan 8, 2021
@kewne
Copy link
Author

kewne commented Jan 13, 2021

My mental model of mockServer.verify is that it goes through the list of expectations, checking if they match the recorded interactions.
In the synchronous case, it either succeeds because all expectations matched or fails because they didn't.

In the asynchronous case, it would loop, checking for 4 possibilities:

  1. All the expectations matched, return;
  2. One of the expectations failed because, e.g., you expected a POST followed by a GET but recorded a POST followed by another POST (I'm assuming call order is verified as well, otherwise the interaction might happen later/out of order and you fall into the next case);
  3. Not all expectations matched but the recorded interactions so far are matches, in which case it waits and retries;
  4. The timeout was reached without all expectations being matched.

In essence, something like this but more polished:

success = false;
while (elapsed() < timeout && !success) {
  try {
    verify();
    success = true;
  } catch (Exception e) {
    // ignore failed verifications
  }
}
if (!success) { throw TimeoutException(); }

@spring-projects-issues spring-projects-issues added status: feedback-provided Feedback has been provided and removed status: waiting-for-feedback We need additional information before we can continue labels Jan 13, 2021
@rstoyanchev
Copy link
Contributor

Expectations are ordered by default but that can be turned off. In any case, regardless of the ExpectationManager used, it comes down to a list of expectations all of which should be satisfied. If any fail, there would be a failure recorded immediately. This should be fairly straight forward to implement. I'll give it a try.

@rstoyanchev rstoyanchev self-assigned this Jan 13, 2021
@rstoyanchev rstoyanchev added this to the 5.3.4 milestone Jan 13, 2021
@rstoyanchev rstoyanchev removed status: feedback-provided Feedback has been provided status: waiting-for-triage An issue we've not yet triaged or decided on labels Jan 13, 2021
This was referenced Mar 13, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: test Issues in the test module in: web Issues in web modules (web, webmvc, webflux, websocket) type: enhancement A general enhancement
Projects
None yet
Development

No branches or pull requests

4 participants