api/schema: remove MethodTestCase in favor of AssertSchema()
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.
2016-05-19 15:52:29 +00:00
|
|
|
package api_test
|
|
|
|
|
|
|
|
import (
|
|
|
|
"testing"
|
|
|
|
|
|
|
|
"github.com/github/git-lfs/api"
|
2016-05-24 15:29:58 +00:00
|
|
|
"github.com/stretchr/testify/assert"
|
api/schema: remove MethodTestCase in favor of AssertSchema()
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.
2016-05-19 15:52:29 +00:00
|
|
|
)
|
|
|
|
|
2016-05-20 15:51:59 +00:00
|
|
|
// AssertRequestSchema encapsulates a single assertion of equality against two
|
api/schema: remove MethodTestCase in favor of AssertSchema()
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.
2016-05-19 15:52:29 +00:00
|
|
|
// generated RequestSchema instances.
|
|
|
|
//
|
2016-05-20 15:51:59 +00:00
|
|
|
// This assertion is meant only to test that the request schema generated by an
|
|
|
|
// API service matches what we expect it to be. It does not make use of the
|
|
|
|
// *api.Client, any particular lifecycle, or spin up a test server. All of that
|
|
|
|
// behavior is tested at a higher strata in the client/lifecycle tests.
|
api/schema: remove MethodTestCase in favor of AssertSchema()
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.
2016-05-19 15:52:29 +00:00
|
|
|
//
|
2016-05-20 15:51:59 +00:00
|
|
|
// - t is the *testing.T used to preform the assertion.
|
api/schema: remove MethodTestCase in favor of AssertSchema()
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.
2016-05-19 15:52:29 +00:00
|
|
|
// - Expected is the *api.RequestSchema that we expected to be generated.
|
|
|
|
// - Got is the *api.RequestSchema that was generated by a service.
|
2016-05-20 15:51:59 +00:00
|
|
|
func AssertRequestSchema(t *testing.T, expected, got *api.RequestSchema) {
|
api/schema: remove MethodTestCase in favor of AssertSchema()
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.
2016-05-19 15:52:29 +00:00
|
|
|
assert.Equal(t, expected, got)
|
|
|
|
}
|