Support for WireMock default instance

[scordio]

I'm looking at how to replace spring-cloud-contract-wiremock with wiremock-spring-boot in one of my projects (scordio/spring-batch-notion#25) and I noticed the configuration becomes a little more verbose.

Specifically:

• @AutoConfigureWireMock(port = 0) is replaced by @EnableWireMock(@ConfigureWireMock(name = "wiremock", property = "wiremock.server.url"))
• Wherever WireMock static methods like givenThat were used, I must use instead a WireMockServer instance injected via @InjectWireMock("wiremock")

In my use case, I don't need custom configurations or the support of multiple instances per test execution, therefore relying on the WireMock default instance would be enough.

I'd like to propose an enhancement where:

• The declaration of @EnableWireMock without any additional @ConfigureWireMock sets up the WireMock default instance on a random available port
• The port would be injected into a wiremock.server.port property, mimicking Spring Could Contract WireMock for some convention over configuration
• Wiremock static methods work with the default instance and without the need to inject it via @InjectWireMock (although nothing should prevent its usage)

If you agree with the idea, I'll be happy to investigate it.

[maciejwalkowiak]

If I understand it right, with these enhancements, this library would become a superset of Spring Cloud Contract WireMock and at least initially it wasn't a goal.

Why are you migrating from Spring Cloud Contract WireMock when it seems that what it offers fits your needs?

[scordio]

Mostly because of the smaller footprint of transitive dependencies, kind of related to spring-cloud/spring-cloud-commons#1260

[maciejwalkowiak]

Understood. I think we can go this route. What I'm wondering, perhaps Instead of using @EnableWiremock, @ConfigureWireMock wiht no configuration would set up default instance, and also it would be possible to use it without @EnableWireMock. Also, make @ConfigureWireMock repeatable. What do you think?

[scordio]

So, if I got it correctly, something like:

@SpringBootTest
@ConfigureWireMock // default instance on random port
class MyTests {
  ...
}

but also:

@SpringBootTest
@ConfigureWireMock(name = "server1", property = "server1.url")
@ConfigureWireMock(name = "server2", property = "server2.url")
class MyTests {
  ...
}

right?

Would this also mean deprecating @EnableWireMock?

[maciejwalkowiak]

Yes, this is what i have in mind but can't guarantee if this is a good idea without really digging through it. @EnableWireMock is currently used to enable JUnit extension - perhaps it can be added to @ConfigureWireMock - not sure how JUnit behaves if same extension is enabled more than once.

Also, @EnableWireMock would probably need to stay for repeatable annotations, but if there is a way to get rid of it, it may be a good idea.

The only utility I still see for @EnableWireMock is to configure customizer that gets applied to all WireMock instances - so perhaps lets keep it for now and decide if it is worth dropping later.

[scordio]

Would you prefer to look into this topic by yourself or should I give it a try in the upcoming days? I assume you're not in a rush as I was the one asking for it 🙂

not sure how JUnit behaves if same extension is enabled more than once.

In my experience, an extension is invoked only once even when it's registered multiple times. However, with a quick search in the docs, I couldn't find anything official about it – I'll check better and reconfirm.

[maciejwalkowiak]

Give it a try please. As much as I would like to I am sure I won't have time for it in upcoming weeks. Thank you!

[tomasbjerre]

I opened #34 and #36, I think they are what you want with the last 2 issues in your list.

I can also add another issue with Spring Could Contract WireMock is that it uses WireMock 2 and are not in a hurry to use 3.x.y, see spring-cloud/spring-cloud-contract#2092 (comment)

This blocks us from using new extensions.

[tomasbjerre]

@maciejwalkowiak do you think you may have time to look at my pr:s?

If you can just merge the filesystem mappings, and the port property, that would make our switch to this library much simpler.

[tomasbjerre]

@scordio I think what you are looking for is merged (not yet released).

I'll close this issue now and you can try it once we manage to make the first release from Wiremock org...

[scordio]

Thanks for getting back to me, @tomasbjerre! I'll try out the current build and give feedback.

And congrats to @maciejwalkowiak for getting his project into WireMock!

[scordio]

@tomasbjerre successfully tested and integrated in scordio/spring-batch-notion#25.

Thanks!