You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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
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.
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.The text was updated successfully, but these errors were encountered: