It isn't a replacement for other types of testing, but rather compliments it and provides quicker feedback and enhanced visibility, some teams may decide they want to use alternative methods, they may have really good channels of communications, endpoints and payload structures don't change often, or systems aren't that critical. Systems that don't change now, will invariably change in the future, either intentionally or accidentally. Having safety blankets helps 🙂 people in teams move on, people come in with new ideas.

we use cypress to test our individual services, but need to mock out the downstream services in the CI pipeline. We still then have this issue where business logic changes are causing uncaught bugs.

Do folks commonly do this sort of thing with Pact?

I have a question, Yousaf. Pact will validate only the communication between the services. (I mean endpoints). So if we want to emulate an E2E we need work together with the unit tests. Pact for communication and unit tests for functionality, right?

Technical questions: • We are using the

webmock

gem (see Comparisons with other tools) in our unit tests (ruby specs). If we want a client (consumer side) to be validated with Pact we should make a copy of that client to point it to the Pact mock service. What is the best practice here? Should we make a copy, or should we replace

webmock

for that client? • When we define specs on the Consumer side, and we want to generate a pact file, we need to define the request body/response body/headers and finally, execute the code. That's fine. The thing is that we need to code trivial expectations (according to the documentation) too. I understand the expectation on functional tests. But in these cases, there is no a complex logic in the middle, we are testing the Pact tool itself. What is the purpose to create expectations of something we defined a few lines above? I await your responses. Thanks