如何运行和编写测试
运行测试
本节介绍作为贡献者如何测试您对 React Native 的更改。如果您尚未完成，请先完成使用原生代码构建项目的开发环境设置步骤。
JavaScript 测试
运行 JavaScript 测试套件最简单的方法是在 React Native checkout 的根目录中使用以下命令
yarn test
这将使用 Jest 运行测试。
您还应该确保您的代码通过 Flow 和 lint 测试
yarn flow
yarn lint
iOS 测试
请按照 packages/rn-tester 目录中的 README.md 说明进行操作。
然后，返回到 React Native checkout 的根目录并运行 yarn。这将设置您的 JavaScript 依赖项。
此时，您可以通过从 React Native checkout 的根目录调用以下脚本来运行 iOS 测试
./scripts/objc-test.sh test
您也可以使用 Xcode 运行 iOS 测试。打开 RNTester/RNTesterPods.xcworkspace 并通过按 Command + U 或从菜单栏中选择 Product 然后 Test 在本地运行测试。
Xcode 还允许通过其 Test Navigator 运行单个测试。您也可以使用快捷键 Command + 6。
objc-test.sh 确保您的测试环境已设置为运行所有测试。它还会禁用已知不稳定或损坏的测试。在使用 Xcode 运行测试时请记住这一点。如果您看到意外的失败，请首先查看它是否在 objc-test.sh 中被禁用。
iOS Podfile/Ruby 测试
如果您正在修改 Podfile 配置，则可以使用 Ruby 测试来验证这些配置。
要运行 ruby 测试
cd scripts
sh run_ruby_tests.sh
Android 测试
Android 单元测试不在模拟器中运行，而是在您本地机器的 JVM 上运行。
要运行 Android 单元测试，请从 React Native checkout 的根目录调用以下脚本
./gradlew test
编写测试
每当您修复错误或向 React Native 添加新功能时，添加一个涵盖它的测试是一个好主意。根据您所做的更改，可能有不同类型的测试适合。
JavaScript 测试
JavaScript 测试可以在 __test__ 目录中找到，与正在测试的文件位于同一位置。有关基本示例，请参阅 TouchableHighlight-test.js。您还可以按照 Jest 的 测试 React Native 应用 教程了解更多信息。
iOS 集成测试
React Native 提供了便利措施，可以更轻松地测试需要原生组件和 JS 组件跨 bridge 通信的集成组件。
两个主要组件是 RCTTestRunner 和 RCTTestModule。RCTTestRunner 设置 React Native 环境，并提供将测试作为 Xcode 中的 XCTestCase 运行的工具（runTest:module 是最简单的方法）。RCTTestModule 作为 NativeModules.TestModule 导出到 JavaScript。
测试本身是用 JS 编写的，并且必须在完成时调用 TestModule.markTestCompleted()，否则测试将超时并失败。
测试失败主要通过抛出 JS 异常来指示。也可以使用 runTest:module:initialProps:expectErrorRegex: 或 runTest:module:initialProps:expectErrorBlock: 测试错误情况，这将期望抛出错误并验证错误是否与提供的条件匹配。
有关示例用法和集成点，请参阅以下内容
iOS 快照测试
一种常见的集成测试类型是快照测试。这些测试渲染组件，并使用 FBSnapshotTestCase 库在后台，使用 TestModule.verifySnapshot() 验证屏幕快照与参考图像是否一致。参考图像通过在 RCTTestRunner 上设置 recordMode = YES，然后运行测试来记录。
快照在 32 位和 64 位以及各种操作系统版本之间会略有不同，因此建议您强制测试使用正确的配置运行。
还强烈建议模拟所有网络数据以及其他可能存在问题的依赖项。有关基本示例，请参阅 SimpleSnapshotTest。
如果您在 pull request 中进行了影响快照测试的更改，例如向其中一个被快照的示例添加了新的示例用例，则需要重新记录快照参考图像。
为此，请在 RNTester/RNTesterSnapshotTests.m 中将 recordMode 标志更改为 _runner.recordMode = YES;，重新运行失败的测试，然后将 record 翻转回 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 提供了一个 命令行界面，能够在本地运行作业。
F.A.Q.
如何升级 CI 测试中使用的 Xcode 版本？
当升级到新版本的 Xcode 时，首先请确保它受 CircleCI 支持。
您还需要更新测试环境配置，以确保测试在 CircleCI 机器中安装的 iOS 模拟器上运行。
这也可以在 CircleCI 的 Xcode 版本参考 中找到，方法是单击所需的版本并在 Runtimes 下查找。
然后您可以编辑这两个文件
-
.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 值。