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.
One of the things I'd mentioned that I disliked about the initial
implementation of MethodTestCase was that it required you to type out three
things (see previous commit). Of particular importance are items (2) and (3),
the expected and actual response, one a Go type, the other a JSON string.
This commit reduces that typing by 1/2. Since all we were doing was typing the
same data in two different formats, the only thing that we were really testing
was the encoding/json package. That is redundant, and a bad boundary to include
during testing. Therefore, instead of having to type out the JSON-encoded
string, this commit delegates that responsibility into the MethodTestCase's
server, and just uses a `json.Encoder` to do the work.
Sweet!
The initial thought here is to introduce a MethodTestCase type that
encapsulates the behavior of testing a single method in a particular given
service.
To do so, a httptest.Server is created and the schema is turned into a request
which is fired at that server. Thet MethodTestCase, of course, knows how to
respond to different requests, and the behavior of those responses is tested.
What I dislike is that we have to write three things which are mostly the same
to test any endpoint in any case on the API:
1) a request type (Go struct)
2) an expected response type (Go type)
3) the actual response (a mutltline Go string, which is really just JSON)
This seems redundant, so I may explore other options for implementing this sort
of thing in the future.
