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

Improvement - Add corresponding test file for generated code. #74

Closed
jacklaaa89 opened this issue Apr 3, 2018 · 2 comments
Closed

Improvement - Add corresponding test file for generated code. #74

jacklaaa89 opened this issue Apr 3, 2018 · 2 comments
Projects

Comments

@jacklaaa89
Copy link

It would be nice if the generated code had a corresponding _test.go file with it so that we could have the coverage when including the generated code file into our codebase.

@vektah
Copy link
Collaborator

vektah commented Apr 3, 2018

Interesting idea. How would this work? The schema might tell you enough for basic types, some of the time, eg 'string' = 'asdf', but what about custom scalars? use the zero value? but I feel like getting tests to pass any user implemented validation (eg user id must be a valid id) would be really tricky. It probably ends up looking like the apollo mocking api but backwards.

I usually write tests to cover the graph manually, executing mutations and asserting that they are present in the query. There is a client package in this repo to make that a little easier. Take a look at the tests in any of the examples eg

@jacklaaa89
Copy link
Author

I think that the tests for the generated code should only test that the code generated is valid and does what is expected. In this scenario we could mock the Resolvers interface generated as this is the root node to the query (the query and mutation fields) and we can control from the top level the objects which are returned and resolved further down the tree, assuming that we can initialise user generated mocks, using the structures themselves or a package like mock

I think that these tests should not have to worry about user implemented validation, as stated above we can control the objects returned from root nodes, and any resolver funcs lower down the tree.

As you stated, the difficulty is in Custom scalar types.

@vektah vektah added this to Performance in 1.0 Release Jun 29, 2018
@vektah vektah moved this from Performance to Bugs in 1.0 Release Jun 29, 2018
@vektah vektah closed this as completed Jul 14, 2018
1.0 Release automation moved this from Bugs to Done Jul 14, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
1.0 Release
  
Done - 0.4.0
Development

No branches or pull requests

2 participants