Testing using wormwood

I think, I go it this library makes absinthe feel like working with graphql in nodejs.

The gql files wormwood/assets at 0.1.0 · wormwood-elixir/wormwood · GitHub
Absinthe implementation: wormwood/lib/examples at 0.1.0 · wormwood-elixir/wormwood · GitHub
Test examples: wormwood/test/examples at 0.1.0 · wormwood-elixir/wormwood · GitHub

Does anyone have any opinions regarding this testing framework?

Hi @wolfiton! Since your question is quite specific, it can take a day (or a couple of days) before someone who uses Wormwood + Absynthe to get back to you, so hang tight .

Hey @wolfiton,

I literally just integrated Wormwood into my application, so I am by no means an expert, but I can walk you through what it looks like for me.

First, I created the queries that I wanted to test. These are the .gql files that you saw in the assets folder in the Wormwood project. These are the queries that are going to be run against your GQL schema, the same as what will happen on the frontend. I put mine in a folder called test/support/queries, and then created different ones for each use case: one to feature current user data, one to fetch data based on a slug, one to fetch all the data associated with a model, etc.

Second, I created the tests themselves. This I put into a folder called test/myproject_web/schema. Here is an example of what the test looks like. My application is a book tracking application, hence the usage of book related info.

defmodule MyAppWeb.Test.BooksSchemaTest do
  use MyApp.DataCase, async: true
  use Wormwood.GQLCase

  load_gql(MyAppWeb.Schema.Schema, "test/support/queries/books.gql")

  describe "books.gql" do
    test "should return all 6 books" do
      result = query_gql()
      {:ok, query_data} = result
      assert length(get_in(query_data, [:data, "books"])) == 6
    end
  end
end

Some things to note.

1. I have use MyApp.DataCase, async: true at the top, which is different from docs. Just due to how my database is setup, I need this to run my tests.
2. The line load_gql(MyAppWeb.Schema.Schema, "test/support/queries/books.gql") basically says "my GQL schema is located in the module that is the first argument, and I want to run the query located in the file at the second argument).
3. query_gql() will run the query, and return the result in an OK tuple. The rest is just the test logic. In my case, I am checking that after I run the query, it returns 6 different books, as that is the number of books I have included in my seed.exs.

As for my opinions of the framework, they aren’t too fleshed out, but I can give you some first thoughts. I do like it because it seems like an easy way to test the actual GraphQL queries. I was testing the functions that my queries resolve to before (and still am), which was pretty close, but this is nice because it is just one extra layer of abstraction. Also, I don’t need to try entering things into Graphiql, and instead can just look at my test queries and run them if I want to see how they’re going to behave, meaning they serve as a bit of documentation. Finally, more tests are always nice.

I hope that helps.

Awesome, thanks @Darin for sharing your thoughts and experience with this testing framework.

I also have a couple of questions if you don’t mind:

Have you tested any middleware or a subscription with this testing framework yet?

Does dataloader work with this testing framework?

Do you think it will be supported long term?

Just tried your method for a simple test and it works great. Thanks for sharing.

Has problems when you use something like this in the schema

@desc "Queryable fields for Blog Articles"
  query do
    field :blog_articles, list_of(:blog_article) do
      resolve(fn _, _, _ ->
        {:ok, Blog.list_articles()}
      end)
    end
  end

  @desc "define fileds that can be acessed for Blog queries"
  object :blog_article do
    field :id, :id
    field :title, :string
  end
end

The gql files will not recognize this format and it will not translate to BlogArticle and BlogArticles it will just give errors for test with invalid argument and return nil.

I feel that this is a bug.

Because if I use : :article and :articles it will translate to Article and Articles.

No problem.

Have you tested any middleware or a subscription with this testing framework yet?

Not yet. I do have some simple middleware I use for authentication that might be an easy one to test. I might try that over the weekend, and I could inform you of what my experiences are. I haven’t tried mocking the authentication stuff at all for testing, so I’m not really sure what I’ll run into.

Does dataloader work with this testing framework?

I have dataloader setup for the queries that I tested and it seemed to work just fine. I haven’t gone into the logs or anything to check that the queries themselves are done in bulk, but I don’t see why not.

Do you think it will be supported long term?

I can’t answer this one for sure. The last commit was in late October of last year, and it doesn’t seem to be insanely popular with only 41 stars so I doubt there will be much community contribution at this point. However, my mindset is that I need to test these GraphQL queries, and this seems like a good way to do it now. If in the future another library pops up that seems to be more maintained and popular it’ll probably be a lot easier for me to swap them out if I have already broken out my .gql files and specific GraphQL test cases. Therefore I think it’s probably more worth my time to just jump in and start writing some tests using Wormwood rather than let the analysis paralysis set in.

Thanks have you encounter my problem in #post7 with the naming problems?

Will you contribute to wormwood testing framework, because it seems that you find it useful and use it in your projects?

Because if you would, I would like to join in and try to help with what I can to make it very easy to use.

I also find it very useful just thinking that i will already have my graphql setup for the front-end from wormwood so i will not need to write it again for the client(just copy paste).