CODEWITHSUNDEEP
testingpact
Joshua Paul Huang
Joshua Paul Huang

Reputation: 123

PACT contract tests per endpoint

Hi doing some preliminary research regarding contract testing using PACT. In the paradigm in which I am using a pact broker to host the pacts, I understand from a high level that there needs to be a contract test on the consumer side which runs a set of tests against the pact mock server...which would then be published to the pact broker. The provider would also need a contract in which it uses the pact created by the consumer on the pact broker to run its test.

My question is this: On the consumer side, is there a need to write multiple different tests for each endpoint?

Upvotes: 0

Views: 1385

Answers (2)

Matthew Fellows
Matthew Fellows

Reputation: 4065

The short answer is yes.

It depends on what each of the API endpoints do. But usually, each endpoint could handle different operations, and depending on the request you would want to make sure your code can handle it (if it uses all of these operations - which is important).

e.g. the following is fairly typical for a "CRUD"-like service:

  1. GET /<resource> with valid request, return 200 and a resource body
  2. GET /<resource> with a bad request, return a 400 and an error body
  3. GET /<resource> without an authentication token, return a 401
  4. POST /<resource> with a valid request, return 201 and a resource id / body
  5. DELETE /<resource> ... and so on

Within each operation and resource, there may be polymorphic payloads (requests or response). If your consumer code has to deal with this, it should have tests for those also.

You might find this page in our docs useful on this topic.

Upvotes: 1

J_A_X
J_A_X

Reputation: 12847

If by endpoint you mean different APIs on different domains, then yes.

The concept of pact is to have interactions between any one consumer/provider pair. As an example, if you have a frontend SPA (the consumer) that uses 2 different APIs (the providers) like an Authentication api (ie. auth.yourdomain.com) and a data API (like data.yourdomain.com), you will want to record the interactions between your frontend and the authentication API as one contract and another contract between the frontend and your data API.

Each of these contracts would have at least one interaction, but could have many, like say, when you do a GET request at the root on the authentication API, it returns X, if you do a POST at /auth with the username/password in the body, it returns Y, etc.

Does that make sense?

Upvotes: 1

Related Questions