I'm trying to write a consumer test for an API method that can receive a post request with email message data and send a corresponding email. The API method returns status code ok if everything is ok but does not return a proper status code in some invalid cases currently. Its not clear to me what to do with the .WithStatus() method: pact.UponReceiving("a request to post an email message with an invalid email address") .WithRequest(HttpMethod.Post, "/v1/Mail") .WithBody(requestBody, "application/json") .WillRespond() .WithStatus(?); I would like to do something like .WithStatus(Match.Type("integer")) but I can see that this is not possible. Is there a way to create a pact that does not care what status code is returned for some invalid cases?

Not currently. Although, if you’re covering invalid cases, you might not be writing a contract test any more - the contract is about defining the behaviour that the consumer relies upon. If the consumer isn’t relying on the behaviour, then you don’t need to write a test for it in the contract.

Thanks for your explanations. My issue is that currently the API method returns the unspecific error 500 as status code in case of an invalid email addess. This is for now considered as acceptable behavior but that status code was implemented for this case in the absence of any specification defining the explicit behavior in this case. Consequently the status code 500 is missing in the API definition file as a possilbe response (because the status codes in the API definition file are based on explicit specifications). So, I'm not sure whether I want to cover an invalid case. This case is not necessary invalid, its just that the status code 500 which is returned in this case is a bit ugly and unspecific (which is why it was not included in the possible responses in the API defintion file for now) and will have to be replaced by a more specific status code. I thought, maybe because I have a bi-directional pact setting between the consumer and provider, I could have the consumer side to be a bit more indifferent for some specific cases.

Right. I’ve faced that problem, and it can be pretty frustrating trying to get provider teams to care about it. Usually my approach is to point out that it’s hard to know how often the service is failing vs usual errors from the logs. 500 is best reserved exclusively for programmer error. If you have a good relationship with them, you could try putting an appropriate error code in the contract, so that it gets corrected when they go to verify it - but I wouldn’t do this without a conversation with them. If you could specify a set of codes, you’d probably want to only give 500 + the code you actually want. Otherwise you’re baking in the assumption that all error codes are acceptable. However, as far as I know, Pact doesn’t support this.

Ok, after explaining the problem to the product owner it was agreed to leave out that interaction in consumer test and create a story to add a better and more specific error code for that case and then add an appropriate interaction in the pact consumer test. So better to go through a bit of additional administrative hassle but remain faithful to the contract testing philosophy.