MethodTestCase had lots of problems, most caused by a good degree of ambiguity
in what we were actually testing.
AssertSchema(), on the other hand, simplifies this problem greatly by correctly
identifying the responsibilities of an *api.RequestSchema. An
*api.RequestSchema is responsible for one thing, and one thing only: to provide
a template for requests to be made against the API, completely regardless of
protocol or implementation.
Most notably, these responsibilities do not include:
- Preforming an HTTP request, or
- reading the response of an http request
So MethodTestCase gets simplified to a simple assert.Equal(). We expect to get
some *api.RequestSchema out, and we expect it to have certain parameters. Now,
all of the API's Service tests are rather simple: create a schema, compare,
rinse and repeat.
The only thing left to do is test the schema of the request and response
payload. This is what I had tried to do with the original MethodTestCase
implementation, but the way the system is desinged, trying to accomplish this
involves integrating with too many unrelated parts. To address this, I plan to
introduce a JSON Schema implementation that compares generated request/reponse
payloads with their ideal types.
