I just created a test account, and there is a problem with the preconfigured example: the URLs are not good. I have a 404 when I access https://github.com/example-organization/Example%20API and https://github.com/example-organization/Example%20API

Hi Jocelyn, I'm not with Pact, but I can see already that that's the same URL twice. And depending on where you got those from, it's very likely you're supposed to replace them with your own repos containing APIs.

hi, thanks for answering. I'm talking about data that is generated at the account creation:

Just discovered the playground: https://playground.clarity.pactflow.io/pacticipants. Same there, yeah, that's just dummy data.

Not entirely dummy I think this is coming from a real sample app, too bad we don't get to see the code.

Which code would you like to see? The application code or the tests?

Aren't the application code and the tests supposed to come from the same place ?

Supposed to? Not sure there are rules 😅

I'm in the process of using such a SDK to generate contracts, so it's nice to read code in order to understand the way to do things. And if it is a Java app, I could event fork the repo and experiment.

We're on the JVM as well, and I haven't seen an up-to-date(!) fully working example. Best you're gonna get is https://docs.pact.io/implementation_guides/jvm/readme#i-use-java

If it helps, I got this one too: https://github.com/pact-foundation/pact-workshop-jvm-spring/tree/main

But conceptually it's always the same. On the consumer side you get some kinda builder and you add the attributes of the contract, and then you save it somewhere or the library does it for you.

And https://github.com/pact-foundation/pact-jvm

🤨 I don't think the complexity of the application plays any role in contract testing. Pact isn't for user/api journey testing. You test one interaction at a time.

I think we should agree to disagree

Maybe 🤷