Add integration tests against a gqlgen server #50
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
benjaminjkraft
requested review from
aberkan,
csilvers,
dnerdy and
MiguelCastillo
benjaminjkraft
force-pushed
the
benkraft.integration
branch
from
158b630 to
4ad4590
Compare
This was
linked to
issues
Aug 19, 2021
Closed
Merged
aberkan
approved these changes
Aug 20, 2021
| // against a real server. | ||
| // | ||
| // These are especially important for cases where we generate nontrivial logic, | ||
| // such as JSON-unmarshaling. |
There was a problem hiding this comment.
You should add a comment pointing about where the test server code is. Otherwise the magic test data appears out of nowhere.
dnerdy
approved these changes
Aug 20, 2021
| @@ -1,11 +1,11 @@ | |||
| # These are the defaults, and are just included to be explicit. | |||
| package: example | |||
| schema: schema.graphql | |||
| queries: | |||
| operations: | |||
There was a problem hiding this comment.
I notice that generation still works when this key is queries since genqlient.graphql is the default value for operations. What do you think about using yaml.UnmarshalStrict to detect invalid keys in the configuration?
There was a problem hiding this comment.
Yeah, that's probably a good idea. This actually confused me for a while, because I copied this config for the integration tests, but actually wanted to change the value, and of course it didn't work. I'll update it in a separate diff.
We have lots of tests covering codegen, but not a lot that actually run the code. For things where all we do is generate types, that's (mostly) fine (especially now that we actually build the code), but as we generate more nontrivial non-type code we need to actually run it. So I wrote some integration tests that spin up a little gqlgen server, and make calls to it; we can add more over time especially as the JSON marshalling logic gets complex (to support fragments). They're more work to write than the snapshot tests, but of course they can test a lot more. In addition to gqlgen, I pulled in testify assert/require, because I really wanted to be able to use assert.Equal and such for these. I didn't bother converting existing tests, although I assume they will become useful elsewhere in time. Both gqlgen and testify are of course only used in tests. Fixes #21 and #24. Issue: #21 Issue: #24 Test plan: make check
benjaminjkraft
force-pushed
the
benkraft.integration
branch
from
4ad4590 to
e4adf41
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary:
We have lots of tests covering codegen, but not a lot that actually run
the code. For things where all we do is generate types, that's (mostly)
fine (especially now that we actually build the code), but as we
generate more nontrivial non-type code we need to actually run it.
So I wrote some integration tests that spin up a little gqlgen
server, and make calls to it; we can add more over time especially as
the JSON marshalling logic gets complex (to support fragments).
They're more work to write than the snapshot tests, but of course they
can test a lot more.
In addition to gqlgen, I pulled in testify assert/require, because I
really wanted to be able to use assert.Equal and such for these. I
didn't bother converting existing tests, although I assume they will
become useful elsewhere in time. Both gqlgen and testify are of course
only used in tests.
Fixes #21 and #24.
Issue: #21
Issue: #24
Test plan:
make check