Should I test all enum values in a contract?

Question

I have a doubt about about whether I should consider a certain type of test functional or contract.

Let's say I have an API like /getToolType, that accepts a {object" "myObject"} as input, and returns at type in the form {type: "[a-z]+"}

It was agreed between client and server that the types returned will match a set of strings, let's say [hammer|knife|screwdriver], so the consumer decided to parse them in an enum, with a fallback value when the returned type is unknown.

Should the consumer include a test case for each type(hammer, knife, screwdriver) to ensure the producer is still following the agreement that it will always return , for instance , the lowercase string "hammer" when /getToolType is called with an hammer object? Or would you consider such a test case as functional? And why?

Answer 1

IMO the short answer is 'no'.

Contract testing is more interested in structure, if we start boundary testing the API we move into functional test [1] territory, which is best done in the provider code base. You can use a matcher to ensure only one of those three values is returned, this should ensure the Provider build can't return other values.

I would echo @J_A_X's comments - there is no right or wrong answer, just be wary of testing all permutations of input/output data.

[1] https://docs.pact.io/best_practices/contract_tests_not_functional_tests.html