Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Write tests for graphql package #24

Closed
benjaminjkraft opened this issue Apr 22, 2021 · 0 comments · Fixed by #50
Closed

Write tests for graphql package #24

benjaminjkraft opened this issue Apr 22, 2021 · 0 comments · Fixed by #50
Assignees
Labels
Milestone

Comments

@benjaminjkraft
Copy link
Collaborator

They don't need to be super detailed -- there's not a lot of code -- but we should really have something!

@benjaminjkraft benjaminjkraft added this to the OSS "launch" milestone Apr 22, 2021
@benjaminjkraft benjaminjkraft changed the title internal: Write tests for graphql package Write tests for graphql package Apr 22, 2021
@benjaminjkraft benjaminjkraft self-assigned this Aug 17, 2021
benjaminjkraft added a commit that referenced this issue Aug 17, 2021
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.
benjaminjkraft added a commit that referenced this issue Aug 17, 2021
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.
benjaminjkraft added a commit that referenced this issue Aug 19, 2021
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.
benjaminjkraft added a commit that referenced this issue Aug 19, 2021
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 benjaminjkraft linked a pull request Aug 19, 2021 that will close this issue
benjaminjkraft added a commit that referenced this issue Aug 20, 2021
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 added a commit that referenced this issue Aug 20, 2021
## 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

Author: benjaminjkraft

Reviewers: aberkan, dnerdy, benjaminjkraft, csilvers, MiguelCastillo

Required Reviewers: 

Approved by: aberkan, dnerdy

Checks: ✅ Test (1.17), ✅ Test (1.16), ✅ Test (1.15), ✅ Test (1.14), ✅ Test (1.13), ✅ Lint, ✅ Test (1.17), ✅ Test (1.16), ✅ Test (1.15), ✅ Test (1.14), ✅ Test (1.13), ✅ Lint

Pull request URL: #50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant