Multiple interactions per test?

[tsfischer]

I feel like I'm missing something, and I don't see any examples of this in the PactSwiftExamples.

I have a couple interactions that require several API calls to be mocked to test properly. For example:

pactMockService
                .uponReceiving("A request for searching foo")
                .given("Computer is set up for foo")
                .withRequest(method: .POST, path: "myTestAPI1", headers: [ "Content-Type": "application/json" ], body:nil)
                .willRespondWith(<...my response for API 1...>)

            pactMockService
                .uponReceiving("A request for processing Foo")
                .given("Computer is set up for foo")
                .withRequest(method: .POST, path: S"myTestAPI2, headers: [ "Content-Type": "application/json" ], body: nil)
                .willRespondWith(<...my response for API 2...>)
                
                pactMockService.run(...

What happens when I do this, is that myTestAPI1 will be flagged as an unexpected API call, because it seems to be overridden by the second interaction.

I'm converting this from PactConsumerSwift, and this all worked fine there.

Thanks!

P.S. I know the obvious response is "separate your tests into single interactions", but I'm trying not to refactor production code at this point.

[surpher]

It relies on .uponReceiving() and .given(). The combination of Strings you put in there must be unique. pactffi (the core built in Rust for all v3 Pact implementations) must be case insensitive.

These two show up in the Pact broker where having multiple of the same will end up with a conflicting and confusing list of interaction descriptions.

[tsfischer]

Thanks for your response. I'm not sure if I'm not framing the question properly, or if I'm misunderstanding something..

Within a single pactMockService.run() body, I need a few (2 in the above example) different apis to be called/mocked. However, when I set things up as above, the first mock interaction ("myTestAPI1") is apparently overridden by the second. The mock service tells me that it is not expecting a call to mockTestAPI1 at all.

If I'm misunderstanding something, could you please show me an example? I had this working under PactConsumerSwift.

Thanks much!

[surpher]

Ah okay, I see now what you mean. Though if the requests and responses are 1:1 equal, that still might break things in pactffi even though PactSwift runs all unit tests in isolation. I actually haven't tried that yet.

You should only have one .run() per Xcode unit test:

class YourTestCase: XCTestCase {

  func firstTestForLowercaseFoo() {
       pactMockService
                .uponReceiving("A request for searching foo")
                .given("Computer is set up for foo")
                .withRequest(method: .POST, path: "myTestAPI1", headers: [ "Content-Type": "application/json" ], body:nil)
                .willRespondWith(<...my response for API 1...>)

       pactMockService.run { url, done in
            // trigger network request
            // assertions
            done()
       }
  }

  func secondTestForCapitalisedFoo() {
       pactMockService
                .uponReceiving("A request for searching Foo")
                .given("Computer is set up for foo")
                .withRequest(method: .POST, path: "myTestAPI2", headers: [ "Content-Type": "application/json" ], body:nil)
                .willRespondWith(<...my response for API 1...>)

       pactMockService.run { url, done in
            // trigger network request
            // assertions
            done()
       }
  }

}

edit: updated path

[tsfischer]

Yep I get that. Problem is, the function I need to call within the run needs to call multiple APIs. Is it a limitation of this library that only a single interaction can be mocked at a time (per run body)? Because that's going to be a showstopper for me.

pactMockService
                .uponReceiving("A request for searching foo")
                .given("Computer is set up for foo")
                .withRequest(method: .POST, path: "myTestAPI1", headers: [ "Content-Type": "application/json" ], body:nil)
                .willRespondWith(<...my response for API 1...>)

            pactMockService
                .uponReceiving("A request for processing Foo")
                .given("Computer is set up for foo")
                .withRequest(method: .POST, path: "myTestAPI2, headers: [ "Content-Type": "application/json" ], body: nil)
                .willRespondWith(<...my response for API 2...>)
                
                pactMockService.run(...) {
                     productionFunctionThatWillCallBothAPIs() {
                          <validate>
                     }
                

[surpher]

Are the "multiple APIs" on different providers?

[tsfischer]

No. Same server, just different API paths.

[surpher]

Hmm... that's the pactffi core that must be complaining and doing the approx validation of that request and not PactSwift itself.

Just to validate this (as I don't have a decent project set up for this), if you change the path to something very different, would it work?

[surpher]

If a completely different path would work and if we'd want to support this we would need to talk to pactffi code devs to be able to handle "similar" requests as valid unique requests.
And you're out of luck here unless you refactor your network-request-making method and abstract it more so it is easier to test in isolation.

[surpher]

Thinking more about this... I'll need to track this through PactSwift anyway. There is code flow that only takes the latest interaction set (eg: .given()). pactffi should be okay if paths are different.

[surpher]

I should really stop reading github issues early in the morning. And definitely not reply to them 😅

[surpher]

I've quickly run this case and indeed PactSwift intentionally only validates the latest set interaction in its .run {} block. That's done so it allows us to run multiple tests in isolation, run them concurrently and for multiple providers.

I'll have a look how to expose an interface that would allow setting multiple interactions to be tested with one .run(flag: orSomething) { _, _ in ... }. Can't promise anything.

[surpher]

Actually, might be easier than thought. Can you hold off on this particular case for a day or two so I can run a few more sanity checks on it and write some more unit tests for it?

[surpher]

@tsfischer in the mean time, you can try branch feat/validate-interaction-set (https://github.com/surpher/PactSwift/tree/feat/validate-interaction-set).

How you'd need to do this now (reusing your initial code example):

           let interactionLowercaseFoo = pactMockService
                .uponReceiving("A request for searching foo")
                .given("Computer is set up for foo")
                .withRequest(method: .POST, path: "myTestAPI1", headers: [ "Content-Type": "application/json" ], body:nil)
                .willRespondWith(<...my response for API 1...>)

            let interactionCapitalisedFoo = pactMockService
                .uponReceiving("A request for processing Foo")
                .given("Computer is set up for foo")
                .withRequest(method: .POST, path: "myTestAPI2", headers: [ "Content-Type": "application/json" ], body: nil)
                .willRespondWith(<...my response for API 2...>)
             
             // here's the puddin', the `verify: [Interaction]` argument. 👍 
             pactMockService.run(verify: [interactionLowercaseFoo, interactionCapitalisedFoo]) { url, done in
                // your network call
                // assertions and..
                done() 
             }

Tested it on one of the demo projects and this is the result when one of the requests is invalid.

EDIT: I reconsidered using validate (in screenshot) and used verify instead. This is so it aligns with other Pact implementations' terminology.

[surpher]

If this works fine for you, I'll try and get this released sometime soon.

[tsfischer]

Wow, thanks for all of that. I'll give it a go this morning.

[tsfischer]

This works fantastic! I've now pushed through all my conversion issues and can officially adopt this library for our pact testing. Thanks so much.

If you can get this into an 'official' release soon that would be great.

[surpher]

This is now available from v0.11.0.

[surpher]

@tsfischer ☝️

[tsfischer]

You rock! Thanks again.