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.