Reputation: 221
I am looking into contract testing using PACT and have been finding a lot of examples where one service (consumer) calls another service (provider) over the network via HTTP(s) calls.
However, in my current project (.Net 6 app), the provider also generates clients using Nswag, and these clients are released as Nuget packages. These packages are then used as a dependency in the consumer service. The consumer code calls the client (the service is registered via DI) and this internally calls the provider service over HTTP(s).
So, in such a scenario, does it make sense to perform contract testing? If yes, should the client be tested or considered a consumer since the client controls the data that gets returned to the consumer? If the client and provider service have a successful pact, then the provider and consumer should also work. This also makes sense since a common client can be used by multiple consumers and this makes it easier to maintain contract test cases. In the end, are there any examples that I can refer to get the client-based contract testing going where the client is utilized as a NuGet package?
Thanks in advance.
Upvotes: 0
Views: 207
Reputation: 4065
One challenge with sharing an SDK is that the caller may not know the endpoint they are calling (or the format of certain elements) which may make mocking the APIs cumbersome. The other key trick is allowing the consumer to override the endpoint (in the test, it needs to go to the Pact mock instead of the live service).
One possibility, is to ship a contract along with the SDK that your client then must publish - this has some downsides (loss of visibility into the field level usage). Perhaps the consumer could even whittle the contract down to the scenarios it needs.
I discuss the reasons why testing client SDKs might be helpful here: https://pactflow.io/blog/should-i-write-contract-tests-for-client-sdks/
Upvotes: 0