Hey, all. One of the complaints I am hearing from teams looking at Pact is the amount of work it takes to both create and maintain all the interaction specifications that are included in writing the consumer tests, as well as the work to create and maintain the mocks used by the provider verification tests. We had one team who just didn't have the time to fix the contract tests due to failures when the contract changes, and instead just stopped running the contract tests. I'm curious, have others encountered this challenge? How have you addressed this? Thanks!

I tend to take an aggressive stance on that attitude, I rarely see the point in good faith . . . like, people are saying they're too busy to make sure their software works properly? From a more constructive perspective, I'd want to know where they get their confidence from 🙂 Are there other tests that cover things enough that they don't see the contracts as high-value? Or are there few tests, and things have been manually tested in a rush? Or something else? Also, where is the time pressure coming from? E.g. if the devs had more time would they be happy to write the tests, or is it just an excuse to avoid (perceived) boring/unproductive work?

Andras makes good points (as always). We do hear that provider state maintenance is one of the biggest challenges, and it's one of the reasons we recently released a feature called bi-directional contract testing which does help mitigate the provider state issue https://pactflow.io/blog/introducing-bi-directional-contract-testing/

Thanks. In my case it's maintaining the expectations defined in the consumer tests that is a huge burden. And as I have been thinking about this more, if you have a huge contract that is difficult to maintain, the underlying problem is actually that the API (and likely the underlying service) is poorly designed - a big surface area indicates a service that has poor cohesion and likely high coupling. I am now asking myself, how much time do I want to spend easing the burden of you having to work with such an API, when the right way to solve this problem is to refactor the API and/or the service.

And as I have been thinking about this more, if you have a huge contract that is difficult to maintain, the underlying problem is actually that the API (and likely the underlying service) is poorly designed - a big surface area indicates a service that has poor cohesion and likely high coupling.

That is such a valid point. When tests are hard it's sending you a message that using it is likely also hard.

Thanks, Beth. I am working on an experiment. I was doing it in Python using Jinja2 as a templating language to create templates for various target languages. If you feel another language would be a better fit, let me know. I have just gotten started so no great loss if I go to another language (although I don't know Rust so that could take me some time to pick up). I am using WireMock as v1, but that is generally limited to environments where you can configure your client to send http to Wiremock. Setting up Wiremock to be an HTTPS person-in-the-middle is tricky. You generally need to use an actual HTTP/HTTPS proxy recorder. I know this could be of general use to the community, so if there is a process you like to use to make sure it gets visibility, input and maybe cross-contribution, please let me know how I might do that. On my side I need to see what eBay requires of me before I contribute work to open source.

Sounds great!

👍

Yeah, I reckon.

k

We don't have any formal process yet, but getting some shape around how to contribute pact related tools is something that is right in the job description for @Yousaf Nabi (pactflow.io).

OK. I'll work on it in my internal repo for now, and will coordinate with @Yousaf Nabi (pactflow.io)

I reckon, get a POC going, see how you find it, then if you think it's worth keeping on going, write up something and/or present to an audience who might like to be involved with contributing or testing, and then see where we go from there.

ok sounds good. BTW, the only place I've heard "I reckon" is from farmers in the American West and now, apparently, Auzzies 🙂

HA!

Yes ma'am, I reckon it is

I don't think anyone would think it out of place in australian slang though. we've picked up so much from the US.

Ah I see, I thought maybe it had a shared ancestor from English that went to both American and Australia. But I guess it could have just come from movies

Australia has so much american content, we're very familiar with any lingo that makes it to a screen. Not so much the other way though! Apparently we can be quite hard to understand 😆

Not sure how relevant it is anymore, but re:

I wasn't sure what you meant by this can you explain? What is "balance of coverage" in this context?

> If the refactoring burden is genuinely huge, I also wonder if the balance of coverage is wrong.

You've both kinda covered it with "contract that is likely way too strict and brittle" and "Yes, it's very easy to make overly specific pacts". Sometimes people push too much stuff into Pact (so some testing should move to other areas of the pyramid), or have too many specific interactions that could be generalised a bit.

Got it thanks