How many pact tests? Not very many unless I'm missing something.

[theGhostJW]

Hi,
I watched the presentation on writing consumer tests by @bethesque and drawn the conclusion that pact testing is about "structural" testing of contracts and you would need relatively few tests per client to achieve the objectives of pact testing.

The number of tests written would be roughly proportional to the number of distinct structures of request / response pairs the client code would expect. Maybe a full valid request, a minimal valid request and requests where sub-sections of the response are present / missing based on some business rule. Also known classes of error where the error response structure or error code are different from each other. These tests would be further reduced to those requests / response pairs that affect the client implementation. If the client only used 3 fields on a response, there would be no assertions applied against any other fields and no pact needed that doesn't affect the structure of those fields.

If I had a tax service as part of an enterprise service application, testing the tax rate, offsets and other calculations would be the remit of the team looking after the tax service. Unit / property based tests could be executed by developers and component level tests by QAs within the tax service team.

Pact tests would verify the consumer of this service received the rebate amount, and taxable income fields as expected in the service response (producer test) and the consumer code could actually parse this response (consumer test validation against a mock expected response).

It would be technically possible to execute very specific functional tests, such as bounds tests on income levels, by writing consumer pacts. This would be using pacts as a Trojan horse for tests that should be done by the tax service team and as such is an anti pattern.

Are my ramblings above somewhat in line with the spirit of pact testing or have I misunderstood something?