I’m not sure if this is the correct way to test an API call in with Absinthe. The code works, but I’m not sure if this is what I should be doing for each query? @account %{email: "hey@you.com", password: "herewego"} setup do {:ok, account} = AccountResolver.create(@account, %{}) {:ok, …

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 of…

Thanks for the answers @benwilson512 ! They were both very helpful =) I’ll use that wrapper function and I’m going to have another go at that test to clean up the naming problems and confusing code. Thanks for pointing those things out as I wasn’t sure how far off I was from the right track.

Okay - I’ve revised the test. Here’s what it looks like now if anyone is interested. Thanks again @benwilson512 @account %{email: "hey@you.com", password: "herewego"} setup do {:ok, account} = AccountResolver.create(@account, %{}) {:ok, token} = AccountResolver.login(@account, %{}) …

this solution worked well for me based on brian’s answer 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…

I just wanted to say thanks to @gdub01 for asking about this and the answers that came from it. I am incredibly new to Elixir, GraphQL, and Absinthe and this helped a lot. I’ve written up what I did in order to test both queries and mutations. Testing Absinthe with ExUnit . The main difference is t…

This is cool :slight_smile: I havn’t written any integration tests at the phoenix level for my graphql endpoint so this’ll be helpful when I get there. Self Plug: I test my queries one level down using Kronky So like query = "{ user(id: \"1\") { firstName lastName age } } " {:ok,…

I highly recommend making use of variables within test, at least for any complicated input. It means you don’t have to worry about escaping stuff within the query string.

First of all, thank you @benwilson512 and the Absinthe team for your work! What do you think about bypassing conn using Absinthe.run like so?: test "query for a post by its ID" do {:ok, result} = """ { post(id: 42) { title body } } """ |> Absinthe.…

It’s an option, but I’m not sure it really brings anything to the table. If you want something more like a unit test I’d focus on unit testing whatever business logic function gets called within specific resolvers. For integration level tests this leaves out stuff that can be important like authoriz…

Good points. Thank you so much!

Elixir Programming Language Forum

Absinthe graphql: testing and displaying changeset errors

Questions & Help Questions