Earlier today I was asked to diagnose an issue in some development code. It turned out that the issue was caused by a new stub implementation returning random data which did not match the service specification.
This led to a conversation with other with regards to the correct approach to dealing with this scenario and a number of different view points and I am curious as to what others would say.
The service specification documents states that for this field, we will return nothing, 'A' or 'D'. (optional/string(1))
The stub had been setup at that point to return a value of '8whMJiAIIg', which matched the WSDL definition (string).
We use a pattern that exposes a (wcf/.NET)response object that is populated from the response of the service/stub (translated accordingly) and the implementation of this was written as per the service spec and was checking for the existence of A or D or not returning anything.
Ultimately, because the value was not A or D which it needed to be in this scenario, the code did not return some additional data and it was causing an exception later in the flow.
The conversation went onto Defensive coding and this is where we are split.
So my question is this;
Should we rely on the service implementation/stub to return data as per the spec (this is considered to be an internal, trusted service) or should we always put code in to confirm that the data sent is indeed as per the service spec.