https://linen.dev logo
#general
Title
# general
b

Bas Dijkstra

03/14/2024, 10:57 AM
Hey folks, does anyone know more about the current status of this project? https://bitbucket.org/atlassian/wiremock-pact-generator/src/master/ It's an adapter for WireMock, written by the folks at Atlassian, to auto-generate Pact-compatible consumer-side contracts from traffic to/from a WireMock instance. It still works with the latest WireMock version (3.4.2) but the fact it's not been updated recently is a bit tricky.
l

Lee Turner

03/14/2024, 11:34 AM
To be honest I hadn't seen this project before. I will take a look because I was thinking about this very thing recently
👍 1
b

Bas Dijkstra

03/14/2024, 11:36 AM
It works pretty smoothly, would be a shame if it went to that place where open source projects go to die
FYI, @Lee Turner, the people behind Pact have also reached out to the creators of the library. Here's their comment to me: I reached out to a few of their folks a while back, but the key guy went on leave. I’ll see if I can resurrect the conversion Let's hope someone picks this up
l

Lee Turner

03/15/2024, 4:08 PM
Nice, would be good to promote this more 👍
e

Eric Deandrea

03/19/2024, 2:39 PM
I’ve actually tried/played with that plugin a while back. It didn’t work out very well, at least for my use cases. In each of my tests I set up a wiremock interaction and then do a verification at the end. What I ended up with was a pact contract that had TONS of contracts in them, most of which weren’t relevant or supposed to be part of the contract. Think negative testing - I want to make sure my application is resilient to failures, but those tests shouldn’t be part of a contract.
maybe if i had structured my test classes better (1 test class for all contract tests, another for everything else) it may have worked out better. But even then it would have duplicated the contracts in each test
b

Bas Dijkstra

03/19/2024, 2:47 PM
Yeah, I can see how that happens, as the plugin by default captures everything. There are some ways to reduce this, including regex matchers for paths that should (not) be captured, but that might be a hassle, too. In your case I'd probably just separate the tests and have the ones that include interactions that should go into a contract call a different WireMock instance, and have only that one capture the requests / responses.
In any case, it might be useful to some folks and I'd love to see maintenance on it continue.
e

Eric Deandrea

03/19/2024, 2:48 PM
Even with separation, if more than one test re-uses the same contract, it still spits out the contract multiple times, which isn’t what you want either. But totally agree with you. It would be a great starting point
👍 1