Is there a good way to mock a pact provider service's dependencies during the verification run? I want to seed my fake db with test data when I run my setup functions, but because of the way our service is designed, it is reaching out to other services to get auth data and other such things tangentially related to the contract I'm trying to verify, so even with the fake data the contract is expecting, I'm not accessing that data when the pact verifier runs because the user that it's using can't be retrieved because the pact provider service can't reach the auth service. The traditional methods of mocking that I'm familiar with are all for running unit tests though (like the pytest_mock's MockerFixture.patch, for example) and while I could overwrite the config that contains the base url of the auth service and run another mock server to return the expected user data whenever it's called, that seems like it'll wind up being a lot of extra work and it seems like there's got to be another better solution.

Thinking of the config with the url, would it work without too much extra to add in endpoints to the service when verifying? I'm thinking similar to how in the examples it adds a route for the state endpoint and behaviour there - you could add another auth endpoint so something can get called and just do nothing, then at least it's all in one place together 🤔

I'm not exactly a python expert. Can you monkey-patch a function that's being imported into a class? So it's not an attribute on the class itself...

It gets quite messy and is easy to end up with it not working but yes you should be able to, I'd need to dig out some examples to explain better [it's easy to import from somewhere, but then not mock correctly if you import differently where you're doing the mocking]

Like I may have:

from function_lib import helper_function

class ThingDoer:
    def do_thing(self):
        value = helper_function()
        # < snip out lots of logic on the value >
        return value

I will dig out some examples and get back to you in a bit, just on a call now 🙂

Cool, thank you

Right, so: I have some code which for the "get_auth" goes and uses boto to talk to AWS and get credentials, this is in

bearly_utils/ig.py

in a completely separate package in my test code I can then do:

from bearly_utils import ig

and later:

class MockIgAuth(NamedTuple):
    identifier: str
    password: str
    key: str
    environment: str = "demo"


@pytest.fixture
def patch_bearly_utils(monkeypatch):
    def get_auth(account):
        account_json = json.loads(account)
        mock_account = account_json["account"]["mock"]
        return MockIgAuth(
            identifier=mock_account["identifier"], password=mock_account["password"], key=mock_account["key"]
        )

    monkeypatch.setattr(ig, "get_auth", get_auth)

The key bit with the monkeypatch is you are importing something as

ig

, and where you're using it for real, you have the same import line.... I mean here if I had just

import bearly_utils

and then tried to do

bearly_utils.ig.get_auth

it wouldn't match up with the monkeypatched one. I hope that makes sense 😄 When it's used in the actual non-test code it's called like:

auth = ig.get_auth(account=account)

How do you use pytest fixtures in your provider verification?

Hmm, that one's separate from Pact usage, there isn't actually Pact in where that mocking is happening

Maybe I didn't make my original question clear then. I'm trying to mock out the auth package which my provider service consumes when I'm verifying a pact for this provider. Since the pact verifier script does not use pytest, I don't know how to mock dependencies without it, so I'm stuck

ohhh ok, I thought as you mentioned pytest that you were using it

I wish, that would solve a lot of problems

it's been a while since using unittest, if you mean you're using that instead?

For my provider verification? How would that work?

pact-python/examples/fastapi_provider is using pytest

I run my provider service, then I run the "verify provider" cli and point it at this provider's host/port and provide the pactfile (etiher as a url or as a file path)

yeah, the run_pytest rather than verify_pact route

shoot, I'd have to re-write a lot to do it this way now...

Huge disclaimer around I'm not in any way saying it's the best or even better way 🙂

I thought it would be easier from the perspective of our CI/CD pipeline if the provider logic was the same, so I based it on the verifier cli

if the provider logic was the same

same as? in principle i like the idea of a nice and consistent calling a cli if that's what you meant, but I've gone for wrapping it up everywhere so my ci/cd does a "make test" regardless of what it is where possible (again, it's an approach, rather than necessarily being the best route)

Same as our Java services and our Node services

using cli verifier you mean? makes sense

I got something working. I didn't want to have to rewrite everything to utilize pytest, so I just wrote a handful of mocks manually and managed to get them to work so 👍