Question related to the pactfile generated from tools like wiremock or mountebank : What is the usecase for such pactfile where matchers are not present at the source itself ? Is such pactfile only targeted for bi-directional contract verification supported by pactflow ? as they are not so useful to run as tests for traditional pact provider verification. If yes, then what is the difference in validating the stubs/mocks against the

OpenAPISpecification

for the consumers and validating the tests request/response against the

OpenAPISpecification

using simple library like this ? doesn't it gives the same schema-based validation same as the bidirectional contract verification ?

Is such pactfile only targeted for bi-directional contract verification supported by pactflow ? as they are not so useful to run as tests for traditional pact provider verification.

that’s correct

Thanks @Matt (pactflow.io / pact-js / pact-go), Appreciate the quick response (as always). So with that we are still limited by the schema-based contract testing, which unfortunately does not give higher guarantee and avoid the need for

integrated tests

.

I don’t think Pact fully alleviates all needs for integrated tests, at least, the context matters. Probably you will still have a few of those in most cases

yes, offcourse, I have. In fact I share your articles on the topic to facilitate the discussions with collegues 🙂 btw, I have also experimented with https://specmatic.in/, which does the same.

btw, I have also experimented with https://specmatic.in/, which does the same.

Would love your feedback on usage of it. One thing about it that I’d like to understand is how it tracks the consumer changes over time, and how you know what consumers use which part of the API (amongst other questions)

absolutely those are valid concerns/differences....but unfortunately the user base hardly dive into such level of concerns....they simply copy/paste or record the payloads by invoking the real services and continue using until they find they are stale.

These are the reasons one would use a Pact Broker, which you would have to deal with yourself by building probably similar tooling https://docs.pact.io/pact_broker#can-i-use-pact-without-a-pact-broker

.but unfortunately the user base hardly dive into such level of concerns....they simply copy/paste or record the payloads by invoking the real services and continue using until they find they are stale.

No tool, can mitigate these types of behaviours. They can be addressed by better development practises, and appropriate check points, whereby there is appropriate peer review, which can pick up and challenge bad practises. You are going to get bitten by bugs at some point, at which point. users which to get that feedback is up to them.

they simply copy/paste or record the payloads by invoking the real services and continue using until they find they are stale.

This is an approach, but its reactive, rather than proactive compared to Pact’s approach to CDCT.

So with that we are still limited by the schema-based contract testing, which unfortunately does not give higher guarantee and avoid the need for

integrated tests

.

This isn’t contract testing sole aim (to remove integrated tests) rather to reduce the number of, and to provide feedback sooner, reducing the size of the haystack when understanding failures. In an integrated environment, you get high levels of confidence which you will always want, as your production env will be integrated, but when an error occurs, you want to be able to pinpoint to the root cause, and that is much easier in isolation. If you’ve tested in isolation, and an error occurs in an integration environment, you know that you have certain touch points which are covered by contracts and okay, and the issue exists elsewhere.

@Yousaf Nabi (pactflow.io), I am not debating the usefulness of the CDCT vs schema-based contract testing. I am well aware about the trade-offs. However, my original question was to understand the similarities and limitation of generating the pact files from tools like WireMock and its applicability. As confirmed by Matt, they are not meant for typical CDCT but only useful for BDCT (schema-based only atm). The same level of confidence can also be achieved with tools like swagger-validator for both tests and stubs. There are few minor differences/advantages of using central tools like pact broker, tracking the changes per env/tagging, but those are not compelling enough for brown-field cases to rewrite existing tests using pact.