ApplicationListener<ApplicationReadyEvent> runs before @EnableWiremock-setup

[mixaaaa]

Proposal

Info

We are actually facing the issue that we are having a rest call for a configuration setup being called in an ApplicationListener using the <ApplicationReadyEvent>. Switching from @AutoConfigureWireMock to @EnableWireMock brought us to the problem that our test configuration class is useless. This configuration has an ApplicationStartedEvent-Listener which was running before the ReadyListener and which gave us the opportunity to set up our wiremock-stub.

Because of WireMockSpringJunitExtension.class it seems that all Wiremock server setup is actually running in the @BeforeEach-Phase. This seems to be too late to stub a mock in lifecycle events like application ready or started.

Feature-Request

Add a possibility to run the setup already in the @BeforeClass phase or something similar which gives the opportunity to set up the WireMockServer before Spring lifecycle events.

References

none - sorry

[tomasbjerre]

This would probably enable solving #82

There was also discussion about what the Junit extension does, and maby should not do, here: #73 (comment)

[mixaaaa]

Thanks for fast response and that the implicit hint for registerSpringBean-flag in #73 (comment).

Using this approach I was able to wire the WireMockServer afterwards instead of using static Wiremock.stubFor(). See following solution:

	@Bean
	public ApplicationListener<ApplicationStartedEvent> initMock(WireMockServer wireMockServer) {
		return event -> mockServiceCall(wireMockServer);
	}

	protected void mockServiceCall(WireMockServer wireMockServer) {
		ResponseDefinitionBuilder responseDefinition = aResponse()
				.withHeader("Content-Type", "application/json")
				.withStatus(200)
				.withBodyFile("testFile.json");

		wireMockServer.stubFor(get(urlEqualTo("/api/list/test"))
				.willReturn(responseDefinition));
	}

I still think it could be an upgrade to make it possible in @BeforeClass to already define mocks to be ahead of spring definition. Also making static context holder able to access the wiremock server bean would be nice.

But that's just my thought and it was absolutely my bad to not check the spring context bean possibility before :) In addition this flag could be added to the documentation.