I just thought about how this is dealt how this is...
# general
t
I just thought about how this is dealt how this is when using specs, but they seem to have the same problem. The only difference is, that a client might know, a certain enum value might occur, but it doesn't necessarily know how to deal with it.
m
Hypothetically the client might know all of the enums at a point in time (X). Later on, the provider evolves its API and adds another enum at time (Y) - this is problematic because we don’t know if the consumer can/can’t handle this. The best strategy is for the consumers to be able to guard against this, although that can be harder in practice and other designs might be required (e.g. should it really be an enum, or is another data type warranted? If it’s just a crude state, should the consumer always know what it means and what to do with it? etc.)
👍 1
If the consumer really can’t handle other types, then a regex (or separate test cases) could guard against it. If the provider ever returns something that doesn’t match the enum in the scenarios it needs, it would fail the provider. This might be too restrictive and prevent the evolution of the provider, however, so must be used carefully.
👍 1