大数据如何模拟数据_模拟GraphQL数据的新方法

大数据如何模拟数据

我们如何在Stripe推动React组件测试和示例 (How we power React component tests and examples at Stripe)

GraphQL’s main benefit for frontend developers has always been excellent tooling and developer experience. Chief among those is the ability to easily mock your data. API mocking is critical because it lets you write and test your components without having to run your whole app backend. You can even develop UI components based on a mocked schema when the backend implementation isn’t done yet, speeding up development.

GraphQL对前端开发人员的主要好处一直是出色的工具和开发人员经验。 其中最主要的是轻松模拟数据的能力。 API模拟至关重要，因为它使您无需运行整个应用程序后端即可编写和测试组件。 当后端实现尚未完成时，您甚至可以基于模拟的架构开发UI组件，从而加快了开发速度。

In the last few months, the Dashboard Platform team at Stripe has been integrating GraphQL and Apollo for data fetching in the Stripe Dashboard. Our goal is to create a smooth and productive experience for product developers across the whole company. One of the most important aspects of that is making testing as easy as possible. In service of that outcome, we’ve come up with some new patterns that allow us to mock data with an extremely small amount of code.

在过去的几个月中， Stripe的Dashboard Platform团队一直在整合GraphQL和Apollo以便在Stripe Dashboard中获取数据。 我们的目标是为整个公司的产品开发人员创造一个平稳而富有成效的体验。 其中最重要的方面之一就是使测试尽可能容易。 为了实现这一结果，我们提出了一些新的模式，使我们可以用很少的代码来模拟数据。

I’ll tell you how we:

我会告诉您我们如何：

1. mock GraphQL data for the whole schema
   模拟整个模式的GraphQL数据
2. customize our mocks on a per-component basis
   根据每个组件自定义我们的模拟
3. mock loading and error states with just one line of code
   只需一行代码即可模拟加载和错误状态
4. integrate these mocks into our Jest tests and component explorer
   将这些模拟集成到我们的Jest测试和组件资源管理器中

Put together, these new tools allow us to render UI components that depend on GraphQL data in tests and examples, in all of the states that we need them, without writing code to handle specific requests and responses.

放在一起，这些新工具使我们能够在需要的所有状态下呈现测试和示例中依赖GraphQL数据的UI组件，而无需编写代码来处理特定的请求和响应。

So let’s jump right in! We’ve included all of the code needed to follow along in this post. We welcome someone from the community publishing an npm package based on our approach.

因此，让我们直接进入吧！ 在这篇文章中，我们已经包括了所有需要遵循的代码。 我们欢迎社区中的某人根据我们的方法发布npm软件包。

Special thanks to my colleagues Isaac Hellendag, Oliver Wong, and Jason Divock, who have contributed to these tools and this post.

特别感谢我的同事Isaac Hellendag ，Oliver Wong和Jason Divock，他们为这些工具和这篇文章做出了贡献。

背景：使用graphql-tools模拟数据 (Background: Mocking data with graphql-tools)

There’s a variety of tools out there that make it super easy to mock requests based on a GraphQL schema and queries.

有各种各样的工具可以使基于GraphQL模式和查询的请求模拟变得非常容易。

There’s the original graphql-tools library, the graphql-faker CLI, and now even Apollo Server has mocking built in. I’m partial to graphql-tools because it’s the easiest to customize.

有原始的graphql-tools库， graphql-faker CLI，现在甚至Apollo Server都内置了模拟功能 。 我偏爱graphql-tools，因为它最容易自定义。

Before getting into the new stuff I’m really excited about with per-component customization, I’ll show you the basic mocking setup.

在介绍新内容之前，我对每个组件的自定义感到非常兴奋，我将向您展示基本的模拟设置。

Here’s how you can get a mocked schema up and running super quickly with graphql-tools:

这是使用graphql-tools可以快速启动并快速运行模拟架构的方法：

This approach lets you generate any shape of fake data, just by providing a query. Here’s how we can wire our mocked schema up to our Apollo-powered components using apollo-link-schema and Apollo Client:

这种方法使您仅通过提供查询即可生成任何形式的假数据。 这是我们如何使用apollo-link-schema和Apollo Client 将模拟的架构连接到Apollo支持的组件上的方法：

Now, we can render a component with mocked data anywhere we want, for example in a Jest test, or a component explorer like Storybook. One nice thing is that graphql-tools allows us to pass in custom mocks for our schema on a per-type basis.

现在，我们可以在任何需要的地方渲染带有模拟数据的组件，例如在Jest测试中，或在诸如Storybook之类的组件资源管理器中。 一件好事是graphql-tools允许我们按类型为模型传递自定义模拟。

That lets us make sure that the data we get from our mocks looks somewhat real. The faker library is super useful here because it lets us get somewhat realistic data with low effort.

这使我们可以确保从模拟中获得的数据看起来有些真实。 faker库在这里非常有用，因为它使我们可以faker获得一些实际数据。

Unfortunately, having a mocked schema that returns realistic data isn’t quite enough for a complete mocking setup. Sometimes, you want to have a test or component example display a very specific situation, rather than generic mock data. You also need to make sure your component behaves properly when it gets empty strings, or a really long list, or a loading state or error. And that’s where things get really interesting.

不幸的是，拥有一个返回实际数据的模拟架构还不足以实现完整的模拟设置。 有时，您希望测试或组件示例显示非常具体的情况，而不是通用的模拟数据。 您还需要确保组件在获取空字符串，很长的列表，加载状态或错误时行为正确。 这就是事情变得非常有趣的地方。

使用模拟提供程序按组件自定义模拟 (Customizing mocks on a per-component basis with a mocking provider)

After trying a lot of different approaches, we came up with a neat API that lets us use global mocks while customizing just the types and fields we need to for that particular test or example.

在尝试了许多不同的方法之后，我们提出了一个简洁的API，该API使我们可以使用全局模拟，同时仅自定义特定测试或示例所需的类型和字段。

Here’s what it looks like:

看起来是这样的：

This allows us to make sure that the component gets exactly two todo items, where the first is completed and the second is not. But here’s the best part — the rest of the data comes from the global mocks we have defined for the whole app! So we only have to specify the fields we care about for this particular example.

这使我们可以确保组件恰好获得两个todo ，其中第一个完成，而第二个则没有。 但这是最好的部分-其余数据来自我们为整个应用程序定义的全局模拟！ 因此，我们只需要指定此特定示例关注的字段即可。

That lets us get the best of both worlds — low effort, realistic global mocks, while maintaining the ability to get custom results to demonstrate specific situations on a per-instance basis. So how does it work?

这样一来，我们就可以做到两全其美-事半功倍，逼真的全局模拟， 同时保持了获得自定义结果的能力，可以按实例显示特定情况。 那么它是怎样工作的？

We’ve implemented this via a mocking provider that merges the custom resolvers passed through its props with our global mock resolvers, like this:

我们通过模拟提供程序实现了这一点，该提供程序将通过其props传递的自定义解析器与我们的全局模拟解析器合并，如下所示：

It takes the custom resolvers you pass in, merges it with your global mocks, and then creates a new Apollo Client instance to be used by the component you are testing.

它采用您传入的自定义解析器，将其与全局模拟合并，然后创建一个新的Apollo Client实例，供您正在测试的组件使用。

The most important function here is mergeResolvers, which allows us to merge our globally defined mocks which overrides a specific test case. It’s a little too long to fit into this blog post, but it’s about 50 lines of code: Check out the mergeResolvers function in my coworker Isaac’s Gist.

这里最重要的功能是mergeResolvers ，它使我们能够合并覆盖特定测试用例的全局定义的mergeResolvers 。 这篇博客文章太长了，但大约需要50行代码： 在我的同事Isaac的Gist中查看mergeResolvers函数。

在一行代码中模拟加载和错误状态 (Mocking loading and error states in one line of code)

The system above gets us most of what we need, but it doesn’t have a good way to mock out stuff that’s not actual data — specifically, loading and error states. Thankfully, we can use a similar approach with Apollo Link to create special providers for those cases. For example, here’s a simple provider for mocking a loading state.

上面的系统可以满足我们的大部分需求，但是它没有一种很好的方法来模拟不是实际数据的东西，特别是加载和错误状态。 幸运的是，我们可以对Apollo Link使用类似的方法来为这些情况创建特殊的提供程序。 例如，这是一个用于模拟加载状态的简单提供程序。

That’s right — it’s so small, it fits in a tweet. And here’s how you would use it:

是的-它很小，适合发一条推文。 这是您将如何使用它：

<LoadingProvider>
  <TodoList />
</LoadingProvider>

Super simple! Awesome stuff. And error states are almost as easy.

超级简单！ 很棒的东西。 错误状态几乎一样容易。

You can use this in the same way, but you can also pass a customizable error:

您可以以相同的方式使用此方法，但也可以传递一个可自定义的错误：

<ErrorProvider graphQLErrors={[{message: 'My error message'}]}>
  <TodoList />
</ErrorProvider>

Armed with these three tools — the mocked schema provider with custom resolvers, the loading provider, and the error provider — you can achieve common mocking use cases in a very small amount of code.

有了这三个工具(带有自定义解析器的模拟方案提供程序，加载提供程序和错误提供程序)，您可以用很少的代码来实现常见的模拟用例。

For the more complex use cases, you can still use the built-in react-apollo MockedProvider, which lets you specify totally custom request and response pairs.

对于更复杂的用例，您仍然可以使用内置的react-apollo MockedProvider ，它使您可以指定完全自定义的请求和响应对。

集成到Jest测试和组件浏览器中 (Integrating into Jest tests and your component explorer)

Now that we’ve got an easy way to mock data, loading states, and errors, we can easily integrate them into Jest or a component explorer. We have our own internal component explorer tool, but a commonly used one in the community is React Storybook.

现在，我们已经有了一种简单的方法来模拟数据，加载状态和错误，我们可以轻松地将它们集成到Jest或组件资源管理器中。 我们有自己的内部组件资源管理器工具，但是社区中最常用的工具是React Storybook。

Here’s what a simple Jest test looks like, using mount from Enzyme to render a React component and then check that its contents are what we expect.

这是一个简单的Jest测试，使用Enzyme的 mount渲染一个React组件，然后检查其内容是否符合我们的期望。

And you can use these providers the same way when rendering a component example in Storybook or similar.

在Storybook或类似版本中渲染组件示例时，可以以相同的方式使用这些提供程序。

And that’s how we do it!

这就是我们的方法！

结论 (Conclusion)

We hope that bringing the power of GraphQL to developers at Stripe will make frontend development much more fun and productive, and this is just the beginning of the story. I’m excited to work with such an awesome team at Stripe!

我们希望将GraphQL的功能带给Stripe的开发人员，将使前端开发变得更加有趣和富有成效，而这仅仅是故事的开始。 我很高兴与如此出色的Stripe团队合作！

We’re using our past experience working on frontend teams and technologies to come up with exciting approaches to improve data fetching and API-related tooling. I can’t wait to share more of what we’re working on over the next few months.

我们利用在前端团队和技术方面的过往经验，提出了令人兴奋的方法来改善数据获取和与API相关的工具。 我迫不及待地想分享未来几个月我们正在研究的更多内容。

Please reach out to me on Twitter at @stubailo if you decide to build a package based on this post, have some feedback, or want to chat about GraphQL and React!

如果您决定基于此帖子构建一个软件包，有一些反馈或想与GraphQL和React聊天，请在Twitter上通过@stubailo与我联系。

Also, we’re hiring for many different engineering roles here at Stripe, so please apply if you want to help us build the economic infrastructure of the internet.

此外， 我们在Stripe招聘了许多不同的工程职位 ，因此如果您想帮助我们构建互联网的经济基础架构，请申请。

翻译自: https://www.freecodecamp.org/news/a-new-approach-to-mocking-graphql-data-1ef49de3d491/

大数据如何模拟数据