|
| 1 | +=================== |
| 2 | +Testing in Graphene |
| 3 | +=================== |
| 4 | + |
| 5 | + |
| 6 | +Automated testing is an extremely useful bug-killing tool for the modern developer. You can use a collection of tests – a test suite – to solve, or avoid, a number of problems: |
| 7 | + |
| 8 | +- When you’re writing new code, you can use tests to validate your code works as expected. |
| 9 | +- When you’re refactoring or modifying old code, you can use tests to ensure your changes haven’t affected your application’s behavior unexpectedly. |
| 10 | + |
| 11 | +Testing a GraphQL application is a complex task, because a GraphQL application is made of several layers of logic – schema definition, schema validation, permissions and field resolution. |
| 12 | + |
| 13 | +With Graphene test-execution framework and assorted utilities, you can simulate GraphQL requests, execute mutations, inspect your application’s output and generally verify your code is doing what it should be doing. |
| 14 | + |
| 15 | + |
| 16 | +Testing tools |
| 17 | +------------- |
| 18 | + |
| 19 | +Graphene provides a small set of tools that come in handy when writing tests. |
| 20 | + |
| 21 | + |
| 22 | +Test Client |
| 23 | +~~~~~~~~~~~ |
| 24 | + |
| 25 | +The test client is a Python class that acts as a dummy GraphQL client, allowing you to test your views and interact with your Graphene-powered application programmatically. |
| 26 | + |
| 27 | +Some of the things you can do with the test client are: |
| 28 | + |
| 29 | +- Simulate Queries and Mutations and observe the response. |
| 30 | +- Test that a given query request is rendered by a given Django template, with a template context that contains certain values. |
| 31 | + |
| 32 | + |
| 33 | +Overview and a quick example |
| 34 | +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| 35 | + |
| 36 | +To use the test client, instantiate ``graphene.test.Client`` and retrieve GraphQL responses: |
| 37 | + |
| 38 | + |
| 39 | +.. code:: python |
| 40 | +
|
| 41 | + from graphene.test import Client |
| 42 | +
|
| 43 | + def test_hey(): |
| 44 | + client = Client(my_schema) |
| 45 | + executed = client.execute('''{ hey }''') |
| 46 | + assert executed == { |
| 47 | + 'data': { |
| 48 | + 'hey': 'hello!' |
| 49 | + } |
| 50 | + } |
| 51 | +
|
| 52 | +
|
| 53 | +Snapshot testing |
| 54 | +~~~~~~~~~~~~~~~~ |
| 55 | + |
| 56 | +As our APIs evolve, we need to know when our changes introduce any breaking changes that might break |
| 57 | +some of the clients of our GraphQL app. |
| 58 | + |
| 59 | +However, writing tests and replicate the same response we expect from our GraphQL application can be |
| 60 | +tedious and repetitive task, and sometimes it's easier to skip this process. |
| 61 | + |
| 62 | +Because of that, we recommend the usage of `SnapshotTest <https://github.com/syrusakbary/snapshottest/>`_. |
| 63 | + |
| 64 | +SnapshotTest let us write all this tests in a breeze, as creates automatically the ``snapshots`` for us |
| 65 | +the first time the test is executed. |
| 66 | + |
| 67 | + |
| 68 | +Here is a simple example on how our tests will look if we use ``pytest``: |
| 69 | + |
| 70 | +.. code:: python |
| 71 | +
|
| 72 | + def test_hey(snapshot): |
| 73 | + client = Client(my_schema) |
| 74 | + # This will create a snapshot dir and a snapshot file |
| 75 | + # the first time the test is executed, with the response |
| 76 | + # of the execution. |
| 77 | + snapshot.assert_match(client.execute('''{ hey }''')) |
| 78 | +
|
| 79 | +
|
| 80 | +If we are using ``unittest``: |
| 81 | + |
| 82 | +.. code:: python |
| 83 | + |
| 84 | + from snapshottest import TestCase |
| 85 | +
|
| 86 | + class APITestCase(TestCase): |
| 87 | + def test_api_me(self): |
| 88 | + """Testing the API for /me""" |
| 89 | + client = Client(my_schema) |
| 90 | + self.assertMatchSnapshot(client.execute('''{ hey }''')) |
0 commit comments