快照测试您的GraphQL API

Snapshot testing was popularized by frameworks like Jest in order to quickly and effectively track unintended changes to React components. However, the concept can be taken away from the front end and find equal utility for back-end testing.

快照测试已被诸如Jest之类的框架所普及，以便快速有效地跟踪对React组件的意外更改。 但是，该概念可以脱离前端，并在后端测试中找到相同的效用。

In this article, I’ll show you how to easily achieve large coverage of your API through integration tests using Jest snapshots in Node.js.

在本文中，我将向您展示如何通过使用Node.js中的Jest快照进行集成测试来轻松实现API的广泛覆盖。

In the next few sections, we’ll cover:

在接下来的几节中，我们将介绍：

• The benefits of snapshot testing
  快照测试的好处
• How to set up a testing environment
  如何建立测试环境
• Managing snapshots tests over time
  随着时间的推移管理快照测试

So let's get started.

因此，让我们开始吧。

快照测试的好处 (Benefits of Snapshot testing)

Testing often has a sweet spot. The goal is rarely 100% coverage, but you should aim to use the right kind of testing and find a balance between fluidity and stability.

测试通常有一个优点。 目标很少是100％覆盖，但是您应该以使用正确的测试类型为目标，并在流动性和稳定性之间找到平衡。

Unit testing is king when covering core parts of your application, and I’m not advocating that snapshots should be used here.

当涉及到应用程序的核心部分时，单元测试是最重要的，我不主张在这里使用快照。

Rather their utility is better suited for integration testing and asserting that a given request returns a given response. Through doing this, you will gain wide coverage of all your resolvers while easily being able to change tests as your application grows.

相反，它们的实用程序更适合集成测试，并断言给定请求返回给定响应。 通过这样做，您将获得所有解析器的广泛覆盖，同时可以轻松地随着应用程序的增长而更改测试。

设置测试环境 (Setting Up a Test Environment)

We need a way to send requests to our GraphQL server and capture the response as a snapshot. I am using apollo-server-testing to do this, but you could use something like supertest instead.

我们需要一种将请求发送到GraphQL服务器并将响应捕获为快照的方法。 我正在使用apollo-server-testing执行此操作，但是您可以使用诸如supertest之类的方法 。

To make fewer assumptions about your specific project, I will show an agnostic approach to snapshot testing. In reality, you would want to seed/tear down databases and mock third-party requests for each test.

为了使您对特定项目的假设更少，我将展示一种不可知的快照测试方法。 实际上，您可能希望播种/拆除数据库并模拟每个测试的第三方请求。

Install our two core dependencies:

安装我们的两个核心依赖项：

yarn add apollo-server-testing jest

We will need two files:

我们将需要两个文件：

1. The test cases, as GraphQL query strings for each request.
   测试用例，作为每个请求的GraphQL查询字符串。
2. Our test runner to process and record snapshots for each test case.
   我们的测试运行器处理和记录每个测试用例的快照。

测试用例 (Test cases)

At scale, we would likely create a different test file for each group of resolvers, but for now, let's just assume we have one file called resolvers.test.js.

在规模上，我们可能会为每组解析器创建一个不同的测试文件，但是现在，让我们假设我们有一个名为resolvers.test.js文件。

Here, we can add our test cases, which are an array of objects containing the GraphQL query string and any variables associated with the query:

在这里，我们可以添加测试用例，这些用例是包含GraphQL查询字符串和与查询关联的任何变量的对象数组：

At the bottom of the file, you can see we pass the testCases into a function called runTestCases. We also provide a name for this set of test cases that will be applied to the outputted snapshots.

在文件的底部，您可以看到我们将testCases传递给了名为runTestCases的函数。 我们还为这套测试用例提供了一个名称，该名称将应用于输出的快照。

So let's go ahead and write the test runner itself.

因此，让我们继续编写测试运行器本身。

创建测试运行器 (Creating the test runner)

As you know, snapshot testing is a really quick process. So in its simplest form, we will create a test client and pass each query into it. We then wait for the response and record it.

如您所知，快照测试是一个非常快速的过程。 因此，以最简单的形式，我们将创建一个测试客户端并将每个查询传递给它。 然后，我们等待响应并记录下来。

Now when running the jest command, Jest will record the response under __snapshots__/resolvers.test.js.snap:

现在，在运行jest命令时，Jest将响应记录在__snapshots__/resolvers.test.js.snap ：

From this point forward, you can quickly add and remove tests for each resolver. Depending on your use case, you could even seed/drop a database for each test, providing isolated end-to-end coverage.

从现在开始，您可以快速添加和删除每个解析器的测试。 根据您的用例，您甚至可以为每个测试播种/删除数据库，从而提供隔离的端到端覆盖范围。

随着时间的推移管理快照测试 (Managing Snapshot Tests Over Time)

As your project grows over time and large refactors take place, you can continue to run your tests and see that the snapshots provide the same output. If you need to update a snapshot, run jest -u, which will replace the content.

随着项目随着时间的增长和进行大量重构，您可以继续运行测试，并查看快照提供的输出是否相同。 如果需要更新快照，请运行jest -u ，它将替换内容。

When updating snapshots, it is extremely important to validate that the new output is what you expect. I have seen many developers run jest -u and commit the code without a second thought. This can easily be caught through PR reviews. But when working alone, it's imperative to be strict with this process.

更新快照时，验证新输出是否符合预期非常重要。 我已经看到许多开发人员都在运行jest -u并提交代码而无需再三思。 通过PR评论很容易发现这一点。 但是当单独工作时，必须严格执行此过程。

I use VSCode and have found the diff tool under the source control tab a fantastic way to monitor unintended changes to snapshots when completing refactors.

我使用VSCode，发现在“源代码控制”选项卡下的diff工具是一种出色的方式，可以在完成重构时监视快照的意外更改。

额外信息 (Extra Info)

我要如何传递给createTestClient ？ (What do I pass into createTestClient ?)

In the example above, I passed a method into createTestClient called createServer. This is just an ApolloServer instance containing your resolvers:

在上面的示例中，我将一个名为createServer的方法传递给createTestClient 。 这只是一个包含解析器的ApolloServer实例：

如何处理突变？ (How do I handle mutations?)

createTestClient returns an object containing { query, mutate }. You must pass the corresponding string into the correct method. In the testCases objects, you could add mutations under a key called mutate or write a small function to detect this from the string itself:

createTestClient返回一个包含{ query, mutate }的对象。 您必须将相应的字符串传递给正确的方法。 在testCases对象中，您可以在称为mutate的键下添加mutate或者编写一个小函数从字符串本身中检测出该mutate ：

Let me know if you have any further questions.

如果您还有其他问题，请告诉我。

翻译自: https://medium.com/better-programming/snapshot-testing-your-graphql-api-50d88a5b67d