Open scordio opened 10 months ago
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?
Mostly because of the smaller footprint of transitive dependencies, kind of related to spring-cloud/spring-cloud-commons#1260
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?
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
?
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.
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.
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!
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 https://github.com/spring-cloud/spring-cloud-contract/pull/2092#issuecomment-2081539632
This blocks us from using new extensions.
@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.
I'm looking at how to replace
spring-cloud-contract-wiremock
withwiremock-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"))
givenThat
were used, I must use instead aWireMockServer
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:
@EnableWireMock
without any additional@ConfigureWireMock
sets up the WireMock default instance on a random available portwiremock.server.port
property, mimicking Spring Could Contract WireMock for some convention over configuration@InjectWireMock
(although nothing should prevent its usage)If you agree with the idea, I'll be happy to investigate it.