如何运行和编写测试
运行测试
本节内容将介绍如何测试您作为贡献者对 React Native 所做的更改。如果您尚未完成，请先按照步骤设置您的开发环境以构建原生代码项目。
JavaScript 测试
运行 JavaScript 测试套件的最简单方法是在您的 React Native 检出目录的根目录下使用以下命令：
yarn test
这将使用Jest运行测试。
您还应该确保您的代码通过Flow和 lint 测试。
yarn flow
yarn lint
iOS 测试
请按照packages/rn-tester目录中的README.md说明进行操作。
然后，返回到您的 React Native 检出目录的根目录并运行yarn。这将设置您的 JavaScript 依赖项。
此时，您可以通过在 React Native 检出目录的根目录下调用以下脚本来运行 iOS 测试：
./scripts/objc-test.sh test
您也可以使用 Xcode 运行 iOS 测试。打开RNTester/RNTesterPods.xcworkspace，然后通过按Command + U或从菜单栏中选择Product然后Test来在本地运行测试。
Xcode 还允许通过其测试导航器运行单个测试。您也可以使用Command + 6快捷键。
objc-test.sh确保您的测试环境已设置为运行所有测试。它还会禁用已知不稳定或损坏的测试。运行 Xcode 测试时请牢记这一点。如果您看到意外的失败，请先检查它是否在objc-test.sh中被禁用。
iOS Podfile/Ruby 测试
如果您正在修改Podfile配置，那么 there are Ruby tests that can verify these.
运行 ruby 测试
cd scripts
sh run_ruby_tests.sh
Android 测试
Android 单元测试不在模拟器中运行，而是在本地计算机的 JVM 上运行。
要运行 Android 单元测试，请在您的 React Native 检出目录的根目录下调用以下脚本：
./gradlew test
编写测试
每当您修复 bug 或为 React Native 添加新功能时，最好添加一个涵盖它的测试。根据您所做的更改，可能有不同的测试类型是合适的。
JavaScript 测试
JavaScript 测试位于__test__目录中，与正在测试的文件同处一处。请参阅TouchableHighlight-test.js了解基本示例。您还可以遵循 Jest 的测试 React Native 应用教程以了解更多信息。
iOS 集成测试
React Native 提供了各种工具，可以更轻松地测试需要原生和 JS 组件通过桥接进行通信的集成组件。
主要组件是RCTTestRunner和RCTTestModule。RCTTestRunner设置 React Native 环境，并提供在 Xcode 中将测试作为XCTestCase运行的工具（runTest:module是最简单的方法）。RCTTestModule被导出到 JavaScript，作为NativeModules.TestModule。
测试本身是用 JS 编写的，完成时必须调用TestModule.markTestCompleted()，否则测试将超时并失败。
测试失败主要通过抛出 JS 异常来指示。还可以使用runTest:module:initialProps:expectErrorRegex:或runTest:module:initialProps:expectErrorBlock:来测试错误条件，它们会期望抛出错误并验证错误是否符合提供的标准。
有关示例用法和集成点，请参阅以下内容：
iOS 快照测试
一种常见的集成测试类型是快照测试。这些测试会渲染一个组件，并使用TestModule.verifySnapshot()将屏幕快照与参考图像进行比较，后台使用FBSnapshotTestCase库。通过将RCTTestRunner的recordMode = YES设置为YES，然后运行测试来记录参考图像。
32 位和 64 位以及不同的操作系统版本之间，快照会略有不同，因此建议您强制使用正确的配置运行测试。
强烈建议模拟所有网络数据以及其他可能出现问题的依赖项。有关基本示例，请参阅SimpleSnapshotTest。
如果您对快照测试进行了会影响它的更改（例如，在快照化的示例之一中添加了一个新的示例用例），您将需要重新录制快照参考图像。
要执行此操作，请将recordMode标志更改为 RNTester/RNTesterSnapshotTests.m 中的_runner.recordMode = YES;，重新运行失败的测试，然后将recordMode切换回NO，提交/更新您的 pull request，然后等待 CircleCI 构建通过。
Android 单元测试
当您处理仅通过 Java/Kotlin 代码即可测试的代码时，添加 Android 单元测试是个好主意。Android 单元测试位于packages/react-native/ReactAndroid/src/test/。
我们建议您浏览这些内容，以了解一个好的单元测试可能是什么样的。
持续测试
我们使用CircleCI来自动运行我们的开源测试。每当向 pull request 添加提交时，CircleCI 都会运行这些测试，以帮助维护者了解代码更改是否引入了回归。这些测试也会在提交到main和*-stable分支时运行，以跟踪这些分支的健康状况。
Meta 的内部测试基础结构中还有另一套测试。其中一些测试是 React Native 的内部消费者定义的集成测试（例如，Facebook 应用中 React Native 表面的单元测试）。
这些测试在每次提交到 Facebook 源代码控制中托管的 React Native 副本时运行。当 pull request 导入到 Facebook 的源代码控制时，它们也会运行。
如果其中一项测试失败，您需要 Meta 的人来处理。由于 pull request 只能由 Meta 员工导入，因此导入 pull request 的人应该能够提供任何详细信息。
在本地运行 CI 测试：大多数开源协作者依赖 CircleCI 来查看这些测试的结果。如果您宁愿使用与 CircleCI 相同的配置在本地验证您的更改，CircleCI 提供了一个命令行接口，它能够本地运行作业。
常见问题解答
如何升级 CI 测试使用的 Xcode 版本？
升级到新版本 Xcode 时，首先确保它得到 CircleCI 的支持。
您还需要更新测试环境配置，以确保测试在 CircleCI 机器上安装的 iOS 模拟器上运行。
您还可以通过点击所需版本并查看 Runtimes 下的内容，在CircleCI 的 Xcode 版本参考中找到此信息。
然后，您可以编辑这两个文件：
-
.circleci/config.yml编辑
macos:下的xcode:行（搜索_XCODE_VERSION）。 -
scripts/.tests.env将
IOS_TARGET_OS环境变量编辑为匹配所需的 iOS Runtime。
如果您打算在 GitHub 上合并此更改，请务必通知 Meta 员工，因为他们在导入您的 pull request 时需要更新react_native_oss.py中内部 Sandcastle RN OSS iOS 测试所使用的_XCODE_VERSION的值。