I have a conceptual question: is there any value in writing a contract test for the error case if we don't actually care what error code it was, or about the error message? Let's say I have a grpc call

GetUser

which returns

User

object with username, full name, etc - I can have matchers on those and check that the fields I actually care about are present in the response. But if the user does not exist, my line

u, err := client.GetUser(ctx, userRequest)

(I'm using go) would have a non-nil

err

, and that's the only thing I'm checking - if err is not nil, I'll just return it without parsing. In my consumer test I can specify a provider state saying "user x does not exist" or smth, and write a test case where I verify that mock server does return the error. In my provider test I can read the state and make sure the user does not exist in the db. But I'm not sure I see any value, because the contract literally says "there will be some error, we don't care which one". Maybe I'm missing something? Thanks!

Fair question. I think this rule of thumb is relevant here:

The rule of thumb for working out what to test or not test is - if I don’t include this scenario, what bug in the consumer or what misunderstanding about how the provider responds might be missed. If the answer is none, don’t include it.

(via https://docs.pact.io/consumer#use-pact-for-contract-testing-not-functional-testing-of-the-provider) In this case, i’d suggest it’s not all that useful. From context, the above code could error for any number of reasons - network down, invalid proto file, user doesn’t exist etc.

Thanks!