Hey there, I’m glad you’re using this library!
Let’s take each of your questions in turn.
Testing
The overall approach here is a very common way to do integration level testing. You may also find that the functions you build to handle the resolvers need unit testing if they’re more complex, but often complexity there gets extracted into service type functions that you’d want to unit test anyway.
A couple of things however would make the testing code you have a bit more idiomatic. Most of these things are phoenix conn test related, there isn’t much absinthe specific about this method of testing.
- use
|> post("/api", query_doc)instead of directly setting:body_params - parse the response body into JSON to look for the value you want instead of using
String.contains?. This is particularly important because GraphQL does not use HTTP status codes to indicate errors that may happen on a given field. So for example suppose youraccountfield returned an error"No account found for email hey@you.com". Your tests would actually pass right now, but clearly there’d be an error.
There’s also a few minor things about the testing here that are a bit confusing. Where does the conn part of info.conn come from? What content type header is being set? Why is the :host value being set? Are you using phoenix or just bare plug.
Error handling
It’s definitely common to want to handle changeset errors in a generic way, and definitely noto something you want to have to call explicitly in your resolvers over and over again.
The best solution at the moment is to build a wrapper function that handles this possible return value from the resolver function its wrapping. Here’s an example:
# in your field
resolve handle_errors(&SomeResolver.function/2)
# in your schema module somewhere, or imported thereinto
def handle_errors(fun) do
fn source, args, info ->
case Absinthe.Resolution.call(fun, source, args, info) do
{:error, %Ecto.Changeset{} = changeset} -> format_changeset(changeset)
val -> val
end
end
end
Now all that you have to do is wrap resolvers where you want changesets to be handled in a handle_errors call and you’re good to go. Having to still manually place handle_errors throughout your schema is a bit of an annoyance as well, and so we’re working to finalize a middleware pattern that will let you apply this pattern in an even more generic way. Until then, wrapper functions are the way to go.
