Skip to main content

测试

随着代码库的扩展，你意想不到的小错误和边缘情况可能会引发更大的故障。错误会导致糟糕的用户体验，并最终导致业务损失。防止脆弱编程的一种方法是在将代码发布到野外之前对其进行测试。

¥As your codebase expands, small errors and edge cases you don’t expect can cascade into larger failures. Bugs lead to bad user experience and ultimately, business losses. One way to prevent fragile programming is to test your code before releasing it into the wild.

在本指南中，我们将介绍不同的自动化方法，以确保你的应用按预期工作，从静态分析到端到端测试。

¥In this guide, we will cover different, automated ways to ensure your app works as expected, ranging from static analysis to end-to-end tests.

Testing is a cycle of fixing, testing, and either passing to release or failing back into testing.

为什么要测试​

¥Why Test

我们是人类，人类也会犯错误。测试很重要，因为它可以帮助你发现这些错误并验证你的代码是否正常工作。也许更重要的是，测试可以确保你的代码在未来添加新功能、重构现有功能或升级项目的主要依赖时继续工作。

¥We're humans, and humans make mistakes. Testing is important because it helps you uncover these mistakes and verifies that your code is working. Perhaps even more importantly, testing ensures that your code continues to work in the future as you add new features, refactor the existing ones, or upgrade major dependencies of your project.

测试的价值比你想象的更多。修复代码中错误的最佳方法之一是编写一个失败的测试来暴露该错误。然后，当你修复错误并重新运行测试时，如果它通过了，则意味着错误已修复，永远不会重新引入到代码库中。

¥There is more value in testing than you might realize. One of the best ways to fix a bug in your code is to write a failing test that exposes it. Then when you fix the bug and re-run the test, if it passes it means the bug is fixed, never reintroduced into the code base.

测试还可以作为新人加入团队的文档。对于以前从未见过代码库的人来说，阅读测试可以帮助他们了解现有代码的工作原理。

¥Tests can also serve as documentation for new people joining your team. For people who have never seen a codebase before, reading tests can help them understand how the existing code works.

最后但并非最不重要的一点是，更多的自动化测试意味着更少的时间花在手动 QA 上，从而节省宝贵的时间。

¥Last but not least, more automated testing means less time spent with manual QA, freeing up valuable time.

静态分析​

¥Static Analysis

提高代码质量的第一步是开始使用静态分析工具。静态分析在你编写代码时检查代码是否有错误，但不运行任何代码。

¥The first step to improve your code quality is to start using static analysis tools. Static analysis checks your code for errors as you write it, but without running any of that code.

  • Linters 分析代码以捕获常见错误（例如未使用的代码）并帮助避免陷阱，标记样式指南的禁忌，例如使用制表符而不是空格（反之亦然，具体取决于你的配置）。

    ¥Linters analyze code to catch common errors such as unused code and to help avoid pitfalls, to flag style guide no-nos like using tabs instead of spaces (or vice versa, depending on your configuration).

  • 类型检查可确保你传递给函数的构造与该函数设计接受的构造相匹配，从而防止将字符串传递给需要数字的计数函数。

    ¥Type checking ensures that the construct you’re passing to a function matches what the function was designed to accept, preventing passing a string to a counting function that expects a number, for instance.

React Native 附带了两个开箱即用的此类工具：ESLint 用于 linting，TypeScript 用于类型检查。

¥React Native comes with two such tools configured out of the box: ESLint for linting and TypeScript for type checking.

编写可测试的代码​

¥Writing Testable Code

要开始测试，你首先需要编写可测试的代码。考虑飞机制造过程 - 在任何模型首次起飞以证明其所有复杂系统能够很好地协同工作之前，都会对各个部件进行测试，以确保它们安全且功能正常。例如，机翼通过在极端负载下弯曲进行测试；发动机部件经过耐用性测试；挡风玻璃经过模拟鸟类撞击测试。

¥To start with tests, you first need to write code that is testable. Consider an aircraft manufacturing process - before any model first takes off to show that all of its complex systems work well together, individual parts are tested to guarantee they are safe and function correctly. For example, wings are tested by bending them under extreme load; engine parts are tested for their durability; the windshield is tested against simulated bird impact.

软件类似。你不必将整个程序编写在一个包含多行代码的大文件中，而是将代码编写在多个小模块中，与测试组装的整体相比，你可以更彻底地测试这些模块。通过这种方式，编写可测试的代码与编写干净的模块化代码交织在一起。

¥Software is similar. Instead of writing your entire program in one huge file with many lines of code, you write your code in multiple small modules that you can test more thoroughly than if you tested the assembled whole. In this way, writing testable code is intertwined with writing clean, modular code.

为了使你的应用更具可测试性，首先将应用的视图部分（React 组件）与业务逻辑和应用状态分离（无论你是否使用 Redux、MobX 还是其他解决方案）。这样，你就可以保持业务逻辑测试（不应依赖于 React 组件）独立于组件本身，组件的工作主要是渲染应用的 UI！

¥To make your app more testable, start by separating the view part of your app—your React components—from your business logic and app state (regardless of whether you use Redux, MobX or other solutions). This way, you can keep your business logic testing—which shouldn’t rely on your React components—independent of the components themselves, whose job is primarily rendering your app’s UI!

理论上，你甚至可以将所有逻辑和数据提取移出组件。这样你的组件将专门用于渲染。你的状态将完全独立于你的组件。你的应用的逻辑无需任何 React 组件即可运行！

¥Theoretically, you could go so far as to move all logic and data fetching out of your components. This way your components would be solely dedicated to rendering. Your state would be entirely independent of your components. Your app’s logic would work without any React components at all!

我们鼓励你在其他学习资源中进一步探索可测试代码的主题。

¥We encourage you to further explore the topic of testable code in other learning resources.

编写测试​

¥Writing Tests

编写可测试的代码后，是时候编写一些实际的测试了！React Native 的默认模板附带 Jest 测试框架。它包含一个针对此环境量身定制的预设，因此你无需调整配置即可提高工作效率，并立即进行模拟 - 很快就可以实现 更多关于模拟的内容。你可以使用 Jest 编写本指南中介绍的所有类型的测试。

¥After writing testable code, it’s time to write some actual tests! The default template of React Native ships with Jest testing framework. It includes a preset that's tailored to this environment so you can get productive without tweaking the configuration and mocks straight away—more on mocks shortly. You can use Jest to write all types of tests featured in this guide.

如果你进行测试驱动开发，你实际上首先编写测试！这样，就可以保证代码的可测试性。

¥If you do test-driven development, you actually write tests first! That way, testability of your code is given.

构建测试​

¥Structuring Tests

你的测试应该很短，最好只测试一件事。让我们从用 Jest 编写的示例单元测试开始：

¥Your tests should be short and ideally test only one thing. Let's start with an example unit test written with Jest:

it('given a date in the past, colorForDueDate() returns red', () => {
  expect(colorForDueDate('2000-10-20')).toBe('red');
});

测试由传递给 it 函数的字符串描述。仔细编写描述，以便清楚地了解正在测试的内容。尽力涵盖以下内容：

¥The test is described by the string passed to the it function. Take good care writing the description so that it’s clear what is being tested. Do your best to cover the following:

  1. 给定 - 一些前提条件

    ¥Given - some precondition

  2. 什么时候 - 你正在测试的函数执行的某些操作

    ¥When - some action executed by the function that you’re testing

  3. 然后 - 预期结果

    ¥Then - the expected outcome

这也称为 AAA（安排、行动、断言）。

¥This is also known as AAA (Arrange, Act, Assert).

Jest 提供 describe 函数来帮助构建你的测试。使用 describe 将属于一项功能的所有测试组合在一起。如果需要，描述可以嵌套。你常用的其他函数是 beforeEach 或 beforeAll，可用于设置你正在测试的对象。请阅读 Jest API 参考 中的更多内容。

¥Jest offers describe function to help structure your tests. Use describe to group together all tests that belong to one functionality. Describes can be nested, if you need that. Other functions you'll commonly use are beforeEach or beforeAll that you can use for setting up the objects you're testing. Read more in the Jest api reference.

如果你的测试有很多步骤或有很多期望，你可能希望将其分成多个较小的步骤。另外，请确保你的测试彼此完全独立。套件中的每个测试都必须可以独立执行，而无需先运行其他测试。相反，如果一起运行所有测试，则第一个测试不得影响第二个测试的输出。

¥If your test has many steps or many expectations, you probably want to split it into multiple smaller ones. Also, ensure that your tests are completely independent of one another. Each test in your suite must be executable on its own without first running some other test. Conversely, if you run all your tests together, the first test must not influence the output of the second one.

最后，作为开发者，我们喜欢我们的代码运行良好并且不会崩溃。在测试中，情况往往相反。将失败的测试视为一件好事！当测试失败时，通常意味着某些事情不正确。这使你有机会在问题影响用户之前解决问题。

¥Lastly, as developers we like when our code works great and doesn't crash. With tests, this is often the opposite. Think of a failed test as of a good thing! When a test fails, it often means something is not right. This gives you an opportunity to fix the problem before it impacts the users.

单元测试​

¥Unit Tests

单元测试涵盖代码的最小部分，例如单个函数或类。

¥Unit tests cover the smallest parts of code, like individual functions or classes.

当被测试的对象有任何依赖时，你通常需要模拟它们，如下一段所述。

¥When the object being tested has any dependencies, you’ll often need to mock them out, as described in the next paragraph.

单元测试的很棒之处在于它们可以快速编写和运行。因此，当你工作时，你会得到有关测试是否通过的快速反馈。Jest 甚至可以选择连续运行与你正在编辑的代码相关的测试：监视模式。

¥The great thing about unit tests is that they are quick to write and run. Therefore, as you work, you get fast feedback about whether your tests are passing. Jest even has an option to continuously run tests that are related to code you’re editing: Watch mode.

模拟​

¥Mocking

有时，当你的测试对象具有外部依赖时，你会想要“模拟它们”。 “模拟”是指用自己的实现替换代码的某些依赖。

¥Sometimes, when your tested objects have external dependencies, you’ll want to “mock them out.” “Mocking” is when you replace some dependency of your code with your own implementation.

一般来说，在测试中使用真实对象比使用模拟更好，但在某些情况下这是不可能的。例如：当你的 JS 单元测试依赖于用 Java 或 Objective-C 编写的原生模块时。

¥Generally, using real objects in your tests is better than using mocks but there are situations where this is not possible. For example: when your JS unit test relies on a native module written in Java or Objective-C.

想象一下，你正在编写一个应用来显示你所在城市的当前天气，并且你正在使用一些外部服务或其他依赖来为你提供天气信息。如果服务告诉你正在下雨，你想要显示带有雨云的图片。你不想在测试中调用该服务，因为：

¥Imagine you’re writing an app that shows the current weather in your city and you’re using some external service or other dependency that provides you with the weather information. If the service tells you that it’s raining, you want to show an image with a rainy cloud. You don’t want to call that service in your tests, because:

  • 它可能会使测试缓慢且不稳定（因为涉及网络请求）

    ¥It could make the tests slow and unstable (because of the network requests involved)

  • 每次运行测试时该服务可能会返回不同的数据

    ¥The service may return different data every time you run the test

  • 当你确实需要运行测试时，第三方服务可以离线！

    ¥Third party services can go offline when you really need to run tests!

因此，你可以提供该服务的模拟实现，有效地替换数千行代码和一些联网温度计！

¥Therefore, you can provide a mock implementation of the service, effectively replacing thousands of lines of code and some internet-connected thermometers!

Jest 附带 支持模拟，从功能级别一直到模块级别模拟。

¥Jest comes with support for mocking from function level all the way to module level mocking.

集成测试​

¥Integration Tests

在编写大型软件系统时，各个部分需要相互交互。在单元测试中，如果你的单元依赖于另一个单元，你有时最终会模拟该依赖，并将其替换为假的。

¥When writing larger software systems, individual pieces of it need to interact with each other. In unit testing, if your unit depends on another one, you’ll sometimes end up mocking the dependency, replacing it with a fake one.

在集成测试中，将真实的各个单元组合起来（与你的应用中相同）并一起进行测试，以确保它们的协作按预期进行。这并不是说这里不会发生模拟：你仍然需要模拟（例如，模拟与气象服务的通信），但你需要它们的次数比单元测试少得多。

¥In integration testing, real individual units are combined (same as in your app) and tested together to ensure that their cooperation works as expected. This is not to say that mocking does not happen here: you’ll still need mocks (for example, to mock communication with a weather service), but you'll need them much less than in unit testing.

请注意，有关集成测试含义的术语并不总是一致的。此外，什么是单元测试和什么是集成测试之间的界限可能并不总是很清楚。对于本指南，如果你的测试满足以下条件，则属于 "集成测试"：

¥Please note that the terminology around what integration testing means is not always consistent. Also, the line between what is a unit test and what is an integration test may not always be clear. For this guide, your test falls into "integration testing" if it:

  • 如上所述组合应用的多个模块

    ¥Combines several modules of your app as described above

  • 使用外部系统

    ¥Uses an external system

  • 对其他应用进行网络调用（例如天气服务 API）

    ¥Makes a network call to other application (such as the weather service API)

  • 是否有任何类型的文件或数据库I/O

    ¥Does any kind of file or database I/O

组件测试​

¥Component Tests

React 组件负责渲染你的应用，用户将直接与其输出交互。即使你的应用的业务逻辑具有很高的测试覆盖率并且是正确的，如果没有组件测试，你仍然可能会向用户提供损坏的 UI。组件测试可以分为单元测试和集成测试，但因为它们是 React Native 的核心部分，所以我们将单独介绍它们。

¥React components are responsible for rendering your app, and users will directly interact with their output. Even if your app's business logic has high testing coverage and is correct, without component tests you may still deliver a broken UI to your users. Component tests could fall into both unit and integration testing, but because they are such a core part of React Native, we'll cover them separately.

为了测试 React 组件，你可能需要测试两件事：

¥For testing React components, there are two things you may want to test:

  • 相互作用：确保组件在与用户交互时（例如，当用户按下按钮时）正确运行

    ¥Interaction: to ensure the component behaves correctly when interacted with by a user (eg. when user presses a button)

  • 渲染：确保 React 使用的组件渲染输出正确（例如按钮的外观和 UI 中的位置）

    ¥Rendering: to ensure the component render output used by React is correct (eg. the button's appearance and placement in the UI)

例如，如果你有一个带有 onPress 监听器的按钮，你想要测试该按钮是否正确显示以及该组件是否正确处理点击该按钮。

¥For example, if you have a button that has an onPress listener, you want to test that the button both appears correctly and that tapping the button is correctly handled by the component.

有几个库可以帮助你测试这些：

¥There are several libraries that can help you testing these:

  • React 的 测试渲染器 与其核心一起开发，提供了一个 React 渲染器，可用于将 React 组件渲染为纯 JavaScript 对象，而不依赖于 DOM 或原生移动环境。

    ¥React’s Test Renderer, developed alongside its core, provides a React renderer that can be used to render React components to pure JavaScript objects, without depending on the DOM or a native mobile environment.

  • React Native 测试库 构建在 React 的测试渲染器之上，并添加了下一段中描述的 fireEvent 和 query API。

    ¥React Native Testing Library builds on top of React’s test renderer and adds fireEvent and query APIs described in the next paragraph.

组件测试只是在 Node.js 环境中运行的 JavaScript 测试。它们没有考虑任何支持 React Native 组件的 iOS、Android 或其他平台代码。因此，他们无法让你 100% 确信一切都适合用户。如果 iOS 或 Android 代码中存在错误，他们将找不到它。

¥Component tests are only JavaScript tests running in Node.js environment. They do not take into account any iOS, Android, or other platform code which is backing the React Native components. It follows that they cannot give you a 100% confidence that everything works for the user. If there is a bug in the iOS or Android code, they will not find it.

测试用户交互​

¥Testing User Interactions

除了渲染一些 UI 之外，你的组件还处理 onChangeText for TextInput 或 onPress for Button 等事件。它们还可能包含其他函数和事件回调。考虑以下示例：

¥Aside from rendering some UI, your components handle events like onChangeText for TextInput or onPress for Button. They may also contain other functions and event callbacks. Consider the following example:

function GroceryShoppingList() {
  const [groceryItem, setGroceryItem] = useState('');
  const [items, setItems] = useState<string[]>([]);

  const addNewItemToShoppingList = useCallback(() => {
    setItems([groceryItem, ...items]);
    setGroceryItem('');
  }, [groceryItem, items]);

  return (
    <>
      <TextInput
        value={groceryItem}
        placeholder="Enter grocery item"
        onChangeText={text => setGroceryItem(text)}
      />
      <Button
        title="Add the item to list"
        onPress={addNewItemToShoppingList}
      />
      {items.map(item => (
        <Text key={item}>{item}</Text>
      ))}
    </>
  );
}

测试用户交互时，从用户角度测试组件 - 页面上有什么？互动后会发生什么变化？

¥When testing user interactions, test the component from the user perspective—what's on the page? What changes when interacted with?

根据经验，更喜欢使用用户可以看到或听到的东西：

¥As a rule of thumb, prefer using things users can see or hear:

相反，你应该避免：

¥Conversely, you should avoid:

  • 对组件 props 或状态进行断言

    ¥making assertions on component props or state

  • 测试 ID 查询

    ¥testID queries

避免测试诸如 props 或 state 之类的实现细节 - 虽然此类测试有效，但它们并不面向用户如何与组件交互，并且往往会因重构而中断（例如，当你想重命名某些内容或使用钩子重写类组件时） ）。

¥Avoid testing implementation details like props or state—while such tests work, they are not oriented toward how users will interact with the component and tend to break by refactoring (for example when you'd like to rename some things or rewrite class component using hooks).

React 类组件特别容易测试其实现细节，例如内部状态、属性或事件处理程序。为了避免测试实现细节，最好使用带有 Hook 的函数组件，这使得依赖组件内部变得更加困难。

¥React class components are especially prone to testing their implementation details such as internal state, props or event handlers. To avoid testing implementation details, prefer using function components with Hooks, which make relying on component internals harder.

诸如 React Native 测试库 之类的组件测试库通过仔细选择提供的 API 来促进编写以用户为中心的测试。以下示例使用 fireEvent 方法 changeText 和 press 模拟用户与组件交互，并使用查询函数 getAllByText 在渲染的输出中查找匹配的 Text 节点。

¥Component testing libraries such as React Native Testing Library facilitate writing user-centric tests by careful choice of provided APIs. The following example uses fireEvent methods changeText and press that simulate a user interacting with the component and a query function getAllByText that finds matching Text nodes in the rendered output.

test('given empty GroceryShoppingList, user can add an item to it', () => {
  const {getByPlaceholderText, getByText, getAllByText} = render(
    <GroceryShoppingList />,
  );

  fireEvent.changeText(
    getByPlaceholderText('Enter grocery item'),
    'banana',
  );
  fireEvent.press(getByText('Add the item to list'));

  const bananaElements = getAllByText('banana');
  expect(bananaElements).toHaveLength(1); // expect 'banana' to be on the list
});

此示例并未测试调用函数时某些状态如何变化。它测试当用户更改 TextInput 中的文本并按下 Button! 时会发生什么情况！

¥This example is not testing how some state changes when you call a function. It tests what happens when a user changes text in the TextInput and presses the Button!

测试渲染输出​

¥Testing Rendered Output

快照测试 是 Jest 支持的一种高级测试。它是一个非常强大且底层的工具，因此建议在使用时格外小心。

¥Snapshot testing is an advanced kind of testing enabled by Jest. It is a very powerful and low-level tool, so extra attention is advised when using it.

"组件快照" 是一个类似 JSX 的字符串，由 Jest 中内置的自定义 React 序列化器创建。这个序列化器让 Jest 将 React 组件树转换为人类可读的字符串。换一种方式：组件快照是测试运行期间生成的组件渲染输出的文本表示。它可能看起来像这样：

¥A "component snapshot" is a JSX-like string created by a custom React serializer built into Jest. This serializer lets Jest translate React component trees to string that's human-readable. Put another way: a component snapshot is a textual representation of your component’s render output generated during a test run. It may look like this:

<Text
  style={
    Object {
      "fontSize": 20,
      "textAlign": "center",
    }
  }>
  Welcome to React Native!
</Text>

对于快照测试，你通常首先实现组件，然后运行快照测试。然后，快照测试会创建一个快照并将其作为参考快照保存到存储库中的文件中。然后在代码审查期间提交并检查该文件。未来对组件渲染输出的任何更改都将更改其快照，这将导致测试失败。然后，你需要更新存储的参考快照才能通过测试。这一改变需要再次提交和审查。

¥With snapshot testing, you typically first implement your component and then run the snapshot test. The snapshot test then creates a snapshot and saves it to a file in your repo as a reference snapshot. The file is then committed and checked during code review. Any future changes to the component render output will change its snapshot, which will cause the test to fail. You then need to update the stored reference snapshot for the test to pass. That change again needs to be committed and reviewed.

快照有几个弱点：

¥Snapshots have several weak points:

  • 对于作为开发者或审阅者的你来说，可能很难判断快照中的更改是否是有意为之，或者是否是错误的证据。特别是大型快照很快就会变得难以理解，而且它们的附加值也会变低。

    ¥For you as a developer or reviewer, it can be hard to tell whether a change in snapshot is intended or whether it's evidence of a bug. Especially large snapshots can quickly become hard to understand and their added value becomes low.

  • 当创建快照时，即使在渲染的输出实际上是错误的情况下，它也被认为是正确的。

    ¥When snapshot is created, at that point it is considered to be correct-even in the case when the rendered output is actually wrong.

  • 当快照失败时，人们很容易使用 --updateSnapshot jest 选项来更新它，而没有采取适当的措施来调查更改是否是预期的。因此需要一定的开发者纪律。

    ¥When a snapshot fails, it's tempting to update it using the --updateSnapshot jest option without taking proper care to investigate whether the change is expected. Certain developer discipline is thus needed.

快照本身并不能确保你的组件渲染逻辑是正确的，它们只是擅长防止意外更改并检查被测试的 React 树中的组件是否收到预期的 props（样式等）。

¥Snapshots themselves do not ensure that your component render logic is correct, they are merely good at guarding against unexpected changes and for checking that the components in the React tree under test receive the expected props (styles and etc.).

我们建议你仅使用小快照（请参阅 no-large-snapshots 规则）。如果你想测试两个 React 组件状态之间的变化，请使用 snapshot-diff。如有疑问，请优先选择上一段所述的明确期望。

¥We recommend that you only use small snapshots (see no-large-snapshots rule). If you want to test a change between two React component states, use snapshot-diff. When in doubt, prefer explicit expectations as described in the previous paragraph.

端到端测试​

¥End-to-End Tests

在端到端 (E2E) 测试中，你可以从用户的角度验证你的应用在设备（或模拟器/模拟器）上按预期运行。

¥In end-to-end (E2E) tests, you verify your app is working as expected on a device (or a simulator / emulator) from the user perspective.

这是通过在发布配置中构建应用并对其运行测试来完成的。在 E2E 测试中，你不再考虑 React 组件、React Native API、Redux 存储或任何业务逻辑。这不是 E2E 测试的目的，你在 E2E 测试期间甚至无法访问这些内容。

¥This is done by building your app in the release configuration and running the tests against it. In E2E tests, you no longer think about React components, React Native APIs, Redux stores or any business logic. That is not the purpose of E2E tests and those are not even accessible to you during E2E testing.

相反，E2E 测试库允许你查找和控制应用屏幕中的元素：例如，你实际上可以像真实用户一样点击按钮或将文本插入到 TextInputs 中。然后，你可以断言应用屏幕中是否存在某个元素、它是否可见、它包含什么文本等等。

¥Instead, E2E testing libraries allow you to find and control elements in the screen of your app: for example, you can actually tap buttons or insert text into TextInputs the same way a real user would. Then you can make assertions about whether or not a certain element exists in the app’s screen, whether or not it’s visible, what text it contains, and so on.

E2E 测试让你对应用的部分功能正常运行有尽可能高的信心。权衡包括：

¥E2E tests give you the highest possible confidence that part of your app is working. The tradeoffs include:

  • 与其他类型的测试相比，编写它们更耗时

    ¥writing them is more time consuming compared to the other types of tests

  • 它们运行得慢

    ¥they are slower to run

  • 它们更容易出现不稳定（"flaky" 测试是一种在不更改代码的情况下随机通过和失败的测试）

    ¥they are more prone to flakiness (a "flaky" test is a test which randomly passes and fails without any change to code)

尝试通过 E2E 测试覆盖应用的重要部分：身份验证流程、核心功能、支付等。对应用的非重要部分使用更快的 JS 测试。添加的测试越多，你的信心就越高，但你花在维护和运行它们上的时间也就越多。考虑权衡并决定什么最适合你。

¥Try to cover the vital parts of your app with E2E tests: authentication flow, core functionalities, payments, etc. Use faster JS tests for the non-vital parts of your app. The more tests you add, the higher your confidence, but also, the more time you'll spend maintaining and running them. Consider the tradeoffs and decide what's best for you.

有几种可用的端到端测试工具：在 React Native 社区中，Detox 是一个流行的框架，因为它是为 React Native 应用量身定制的。iOS 和 Android 应用字段另一个流行的库是 Appium 或 大师。

¥There are several E2E testing tools available: in the React Native community, Detox is a popular framework because it’s tailored for React Native apps. Another popular library in the space of iOS and Android apps is Appium or Maestro.

概括​

¥Summary

我们希望你喜欢阅读本指南并从中学到一些东西。你可以通过多种方式测试你的应用。一开始可能很难决定使用什么。然而，我们相信一旦你开始向出色的 React Native 应用添加测试，这一切都会有意义。你还在等什么？提高你的覆盖范围！

¥We hope you enjoyed reading and learned something from this guide. There are many ways you can test your apps. It may be hard to decide what to use at first. However, we believe it all will make sense once you start adding tests to your awesome React Native app. So what are you waiting for? Get your coverage up!

¥Links

本指南最初由 Vojtech Novak 撰写并全部贡献。

¥This guide originally authored and contributed in full by Vojtech Novak.