Testing Components with GraphQL

If you try to run unit tests on components that use GraphQL queries, you will discover that you have no data. Jest can’t run your queries, so if you are testing components that rely on GraphQL data, you will need to provide the data yourself. This is a good thing, as otherwise your tests could break if your data changes, and in the case of remote data sources it would need network access to run tests.

In general it is best practice to test the smallest components possible, so the simplest thing to do is to test the individual page components with mock data, rather than trying to test a full page. However, if you do want to test the full page you’ll need to provide the equivalent data to the component. Luckily there’s a way to get the data you need.

First you should make sure you have read the unit testing guide and set up your project as described. This guide is based on the same blog starter project. You will be writing a snapshot test for the index page.

As Jest doesn’t run or compile away your GraphQL queries you need to mock the graphql function to stop it throwing an error. If you set your project up with a mock for gatsby as described in the unit testing guide then this is already done.

Testing page queries

As this is testing a page component you will need to put your tests in another folder so that Gatsby doesn’t try to turn the tests into pages.

If you run this test you will get an error, as the data prop is not mocked.

In this case, there is no GraphQL data being passed to the component. You can pass this in too, but the structure is a little more complicated. Luckily there’s a way to get some suitable data. Run npm run develop and go to http://localhost:8000/___graphql to load the GraphiQL IDE. You can now get the right data using the same query that you used on the page. If it is a simple query with no fragments you can copy it directly. That is the case here, run this query copied from the index page:

The output panel should now give you a nice JSON object with the query result. Here it is, trimmed to one node for brevity:

GraphiQL doesn’t know about any fragments defined by Gatsby, so if your query uses them then you’ll need to replace those with the content of the fragment.

When you have the result, copy the data value from the output panel. Good practice is to store your fixtures in a separate file, but for simplicity here you will be defining it directly inside your test file:

Run the tests and they should now pass. Take a look in __snapshots__ to see the output.

Testing useStaticQuery

The method above works for page queries, as you can pass the data in directly to the component. This doesn’t work for components that use useStaticQuery though, as that uses React Context rather than props so you need to take a slightly different approach to testing these types of components.

Using useStaticQuery allows you to make queries in any component, not just pages. This gives a lot of flexibility, and avoid having to pass the props down to deeply-nested components. The pattern for enabling type checking described in the docs is a good starting point for making these components testable, as it separates the query from the definition of the component itself. However that example doesn’t export the inner, pure component, which is what you’ll need to test.

Here is the example of a layout component that queries the page data itself:

You’ll need to mock the useStaticQuery call to test the component: