用于 React Native 应用程序的各种测试自动化框架

当今的移动应用程序设置的标准很高。 首先，应用程序必须符合应用程序市场期望的质量标准。 其次，移动应用用户要求很高。 有很多替代品可供下载，因此用户不会容忍有缺陷的应用程序。 由于移动应用程序已成为人们生活中如此重要的一部分，因此用户不会羞于分享他们对应用程序的爱或恨——而且这种反馈会在几秒钟内出现在数百万用户面前。

关于粉碎的进一步阅读：

• 使用 JavaScript 构建您的第一个 iOS 应用程序
• 为什么你应该为你的移动应用考虑 React Native
• 应用程序、游戏和移动网络的测试自动化
• 使用 React、Node 和 Express 进行服务器端渲染
• 关于客户端呈现的可访问性的注释

手机比以往任何时候都更重要。 但是，让一个应用程序恰到好处，让它在所有可能的设备上运行，具有不同的操作系统版本、显示分辨率、芯片组和其他硬件特性，并在所有可能的配置中让用户体验流畅，是一项具有挑战性的任务。

大量优秀的技术、工具、框架和开源组件可用于构建原生移动应用程序。 React Native 为现场带来了什么价值，我们如何确保使用它构建的应用程序受到目标受众的好评？

在本文中，我们将了解可用于测试 React Native 应用程序的内容。 首先，在了解如何实现这些测试之前，我将解释 React Native 的一些关键特性。 其次，我将在三个级别（单元、集成、功能）上对测试方法和框架进行分类，并为每个级别提供示例。 最后，我将提供简单的示例，说明如何使用最流行的开源测试自动化框架来实现功能性应用程序测试。

React Native 应用的基本架构

这一切都始于三年多前的 React，当时 Facebook 将其框架介绍给 Web 开发人员。 它一定会很受欢迎，不仅因为它是由 Facebook 创作和开发的，还因为它为 Web 开发人员提供的功能——尤其是它改变了我们构建应用程序的方式。

不过，这种“一次学习，随处编写”框架的概念并不新鲜。 我们已经看到 JavaScript 库做类似的事情（Sencha、PhoneGap 和 Appcelerator 等等），但是 React 更好的东西对开发人员的习惯以及他们如何将应用程序的 UI 分解为离散组件产生了影响。

React Native 不使用 DOM 进行渲染。 相反，它使用本机 UI 视图呈现，这意味着您使用的是操作系统提供的本机组件。 这种产品创建流程，您将 DOM API 替换为更具声明性的 API，为开发人员提供了更具凝聚力和简化的抽象级别。

React Native 的关键在于它将 React 编程模型带入了移动应用程序、开发和测试。 它实际上并不直接用作跨平台工具或框架，但它加速了在这个新平台上构建移动应用程序的趋势。 这就是让 React Native 在这个新平台上如此强大、易于学习和易于编写的基石之一。

原生移动设备与 Web 的主要区别和优势在于，我们现在依赖于应用程序中的嵌入式 JavaScriptCore，而不是在浏览器中运行基于 JavaScript 的实现并公开 HTML 元素，这些应用程序特定于平台用户界面元素。

不同级别的测试自动化：单元、集成、组件和功能

所有移动软件都是使用组合构建的。 在 Android 和 iOS 上，这意味着将小型软件组件排列在一起以形成更大、更高级别的组件，并具有更强大的功能，直到满足应用程序的目标和要求。 一个好的测试实践是运行涵盖组合所有级别功能的测试。

在本文中，我将介绍三个级别的测试方法和自动化框架。 主要关注的是最高级别的功能测试，但 React Native 应用程序可以在至少以下级别上进行测试——并且测试可以自动化——

• 单元测试
  这甚至可以像在组件级别测试 JavaScript 对象和方法一样基本。
• 组件测试
  每个组件都可以进行视觉或功能测试。 ReactTestUtils 提供了一个简单的框架来测试 React 组件。
• 集成测试
  接下来是集成测试，这是通常将一组不同单元作为一个实体进行测试的阶段。
• 功能测试
  功能测试是一种专注于用户需求和交互的黑盒测试，它涵盖了所有底层软件、所有用户交互和应用程序作为一个实体。

除了 ReactTestUtils，React Native 还提供了有用的单元测试方法，但它们都没有完全覆盖应用程序的实际逻辑。 因此，基于 React Native 构建的移动应用程序从功能 UI 测试中受益更多。 有多种功能测试自动化框架可供使用，我们将在本文中介绍一些最流行的框架。

虽然可以在组件级别进行单元测试，但功能测试自动化提供了更好的功能来测试 React Native 应用程序中的较大实体。 使用 React Native，组件逻辑单元测试可以独立完成，使用传统的 JavaScript 库并强制 React Native 返回常规组件而不是原生组件。 借助功能性测试自动化框架，UI 组件是应用程序的一部分，并且易于作为一个整体进行测试。

我将这些框架分为跨平台框架和特定平台框架，如下图所示。

React Native 应用程序最好的部分是它们对于两个主要移动平台（Android 和 iOS）都是完全原生的。 这意味着我们获得了更多用于测试目的的框架、工具和本地方法。 我们将在下面标题为“将功能测试自动化框架与 React Native 应用程序一起使用”的部分中研究功能测试自动化框架。

让我们从单元测试功能开始，使用一个 JavaScript 测试来说明。

使用 Jest 和 Jasmine 进行单元测试

默认情况下，React Native 为单元测试提供 Jest 测试，这适用于 Android 和 iOS。 目前，测试覆盖率并不完美，但据 Facebook 称，React Native 将引入更多单元测试功能，用户已经可以构建自己的。

Jest 使用 Jasmine 行为驱动框架作为测试 JavaScript 代码的基础。 每个测试用例都从一个describe()函数调用开始，类似于 JUnit 使用TestCase类的方式。 describe()函数有两个参数：测试用例的描述和标题，以及要执行的函数。 it()函数包括所有的测试步骤，并且（类似于 JUnit）提供了一系列的expect()函数。

下面是一个播放器应用程序的 Jasmine 测试脚本示例。

 describe("Player", function() { var player; var song; beforeEach(function() { player = new Player(); song = new Song(); }); it("should be able to play a song", function() { player.play(song); expect(player.currentlyPlayingSong).toEqual(song); //demonstrates use of custom matcher expect(player).toBePlaying(song); }); describe("when song has been paused", function() { beforeEach(function() { player.play(song); player.pause(); }); it("should indicate the song is paused", function() { expect(player.isPlaying).toBeFalsy(); // demonstrates use of 'not' with a custom matcher expect(player).not.toBePlaying(song); }); it("should be possible to resume", function() { player.resume(); expect(player.isPlaying).toBeTruthy(); expect(player.currentlyPlayingSong).toEqual(song); }); }); // demonstrates use of spies to intercept and test method calls it("tells the current song whether the user has made it a favorite", function() { spyOn(song, 'persistFavoriteStatus'); player.play(song); player.makeFavorite(); expect(song.persistFavoriteStatus).toHaveBeenCalledWith(true); }); //demonstrates use of expected exceptions describe("#resume", function() { it("should throw an exception if song is already playing", function() { player.play(song); expect(function() { player.resume(); }).toThrow("song is already playing"); }); }); });

这个基本示例展示了如何使用 Jasmine 测试应用程序的功能，但它仍将重点放在方法级别的测试上。 此外，React Native 还提供了一些测试集成组件的基本能力。 这适用于本机和 JavaScript 组件，并允许它们之间通过网桥进行通信。

集成测试

目前，React Native 社区中突出显示的集成测试仅适用于 iOS，并且测试组件的能力非常有限。 通信通过桥接并需要本机和 JavaScript 组件。 对于此功能，可使用两个组件来实现自定义集成测试，即 RCTestRunner 和 RCTestModule。

用于构建 iOS 应用程序测试框架的基本 Objective-C 示例将如下开始：

 @implementation ExampleTests { RCTTestRunner *_runner; } - (void)setUp { [super setUp]; _runner = RCTInitRunnerForApp(@"IntegrationTestHarnessTest", nil); } - void()testExampleTests { [_runner runTest:_cmd module:@"ExampleTests"] } @end

但是，还有其他方法可以运行集成测试并将其扩展到 Android 和 iOS。 运行单元测试和集成测试的一个很好的选择是 Mocha，它提供了一个在 Node.js 上运行的功能丰富的 JavaScript 测试框架。 Mocha 还提供行为驱动开发 (BDD)、测试驱动开发 (TDD) 和 QUnit 接口用于测试。

对于功能性 UI 测试，我将介绍最突出和最常用的测试自动化框架，包括 Appium、Calabash、XCTest 和其他一些框架。

使用带有 React Native 应用程序的功能测试自动化框架

为了简化应用程序开发过程并最大化测试覆盖率，我们有许多开源测试自动化框架可供选择。

最好的选择——如果你的应用程序将在多个操作系统平台上运行——是一个支持多个平台并为测试自动化提供强大基础的框架。 在移动领域，术语“跨平台”是指为 Android 和 iOS 提供相同 API、工具和功能的框架。

此外，还提供了一系列出色的特定于平台的框架。 自然，每个框架都是为特定平台构建的，并且在大多数情况下，更容易为该平台采用。 除了 Appium 和 Calabash，我将在本文中介绍四个特定于平台的框架：Android 的 Robotium 和 Espresso，以及 iOS 的 XCTest 和 EarlGrey。

在测试自动化方面，请记住使用 React Native 构建的应用程序在 iOS 和 Android 上都是完全原生的； 因此，功能测试自动化框架可以很好地与它们配合使用。

我将与每个框架一起使用的示例是一个非常基本的单选按钮 UI 的实现。

 <Radio onSelect={this.onSelect.bind(this)} defaultSelect={this.state.optionSelected - 1}> <Option color="black" selectedColor="#000000"> <Item title="First option" description="First radio button"/> </Option> <Option color="black" selectedColor="#000000"> <Item title="Second option" description="Second radio button"/> </Option> <Option color="black" selectedColor="#000000"> <Item title="Third option" description="Third radio button"/> </Option> </Radio>

下面每个框架部分中包含的测试片段显示了测试脚本如何处理每个 UI 元素以及如何处理点击和其他用户输入。 这些示例的目的不是提供分步说明，而是比较示例并展示当今可用于测试自动化的内容以及可用于测试的编程语言。

跨平台框架

如前所述，React Native 实际上并不是一个跨平台框架，但在其他平台上采用它很容易。 在接下来的两节中，我们将介绍两个流行的跨平台测试自动化框架，用于移动测试和移动测试自动化。

Appium

Appium 是一个开源测试自动化框架，具有适用于原生、混合和移动 Web 应用程序的检查工具。 它在内部使用 JSONWireProtocol 与 iOS 和 Android 应用程序交互，使用 Selenium WebDriver。 正因为如此，Appium 也非常适用于移动 Web，如果 Selenium 用于 Web 测试，用例也非常相似。

事实上，Appium 在去年一直是移动测试自动化领域的后起之秀。 最初，它旨在为主要平台 Android 和 iOS 提供跨平台支持。

跨平台意味着框架及其脚本在两个平台上的工作方式完全相同。 此外，Appium 提供了出色的编程语言支持——开发人员可以使用他们喜欢的语言（例如，Java、Ruby、Python、C#）、工具和环境编写测试。 它也很容易上手，创建和维护可重用的测试，并在真实的物理设备上执行这些测试。

当涉及到基于 React Native 的应用程序时，不一定需要 JavaScript。 测试可以用任何语言编写。 例如，Appium 脚本可能如下所示：

 driver.findElement(By.id("com.example.app:id/radio0")).click(); driver.findElement(By.id("com.example.app:id/radio1")).click(); driver.findElement(By.id("com.example.app:id/radio2")).click(); driver.findElement(By.id("com.example.app:id/editText1")).click(); driver.findElement(By.id("com.example.app:id/editText1")).sendKeys("Simple Test"); driver.findElement(By.name("Answer")).click(); // or alternatively like this: driver.findElement(By.id("com.example.app:id/button1")).click();

那么，这些 WebDriver 功能如何访问设备上运行的应用程序呢？ 基本上，Appium 在设备或模拟器上启动一个测试脚本，然后创建一个服务器并监听来自 Appium 主服务器的命令。 它与 Selenium 服务器相同，从 Selenium 客户端库获取 HTTP 请求。 Android和iOS的区别如下图所示：

在 iOS 中，Selenium WebDriver 从 Appium 脚本中获取命令（例如click() ）并通过 HTTP 请求以 JSON 的形式将其发送到 Appium 服务器。 Appium 知道自动化上下文并将此命令发送到 Instruments 命令服务器，该服务器等待 Instruments 命令客户端获取它并在 iOS Instruments 环境中使用bootstrap.js执行它。 命令执行后，Instruments 命令客户端将消息发送回 Appium 服务器，Appium 服务器在其控制台中记录与命令相关的所有内容。 这个循环一直持续到测试脚本完成。

在 Android 上，工作方式几乎相同，只是使用的框架是 Selendroid 和 UiAutomator。 简而言之，Appium 将 WebDriver 命令转换为 UiAutomator（API 级别 17 或更高）或 Selendroid（API 级别 16 或更低）命令。 在物理设备上， bootstrap.jar启动一个从 TCP 客户端获取命令的 TCP 服务器。 这个过程在 iOS 上是类似的。

如果您有兴趣开始使用 Appium，可以使用大量材料，包括分步说明和 Appium 教程。

蠡

另一个伟大的跨平台测试框架是 Calabash，它使任何人都可以为移动应用程序编写测试。 主要区别在于 Calabash 测试是用 Cucumber 编写的。 使用这种语言进行测试背后的想法很棒：测试本身就像一个规范，所有测试都简单易读，并且可以由自动化系统执行。

与 Appium 相比，Calabash 提供了一种更简单的方法来为 Android 和 iOS 创建跨平台测试。 这是由于简单的词汇和面向规范的语言，这使得 Calabash 测试在两个平台上都是相同的。 实际测试用 Gherkin 编写并在 Cucumber 中运行。

由于这些功能，Calabash 在 Android 和 iOS 应用程序上的区别很小。 同样，对于 React Native 应用程序没有任何影响，因为所有组件和用户界面都是这些平台完全原生的。

然而，基本的测试和测试创建流程保持不变。 Calabash（和 Gherkin）测试包括功能、场景和步骤。 推荐的方法是首先完成最高级别的描述：功能，然后是场景，然后是实际步骤。 一个好的经验法则是首先创建 Calabash 功能。

下面的示例展示了我们的应用程序及其 UI 组件（单选按钮、文本字段和按钮）如何在 Calabash 中实现：

 Feature: Answer the question feature Scenario: As a valid user, I want to answer app question, I wait for text "What is the best way to test application on a hundred devices?" Then I press radio button 0 Then I press radio button 1 Then I press radio button 2 Then I enter text "Simple Test" into field with id "editText1" Then I press view with id "Button1"

步骤通常以given的关键字之一开始， then 、 when 、 and或but 。 但是，他们不必这样做； 他们可以使用*代替。

Calabash 也被非开发人员广泛使用，由于其易于理解的语言和逻辑，它可以用于产品规范和文档。 最终，这些特性和场景被封装在 Ruby 代码中。

设置 Calabash 并开始使用它很容易。 如果您安装了 Bundler 和 Ruby（或 rbenv），只需在控制台中点击这几行，很快就会设置 Calabash 环境：

 $ gem install calabash-android $ gem install calabash-cucumber

这将负责安装 Calabash-Android 和 Calabash-iOS，您的测试自动化之旅就可以开始了。

平台特定的框架

在 Android 和 iOS 应用程序的自动化测试方面，使用特定于平台的框架比跨平台的框架具有一定的优势。 例如，一些框架与 SDK 和 IDE 密切相关，在开发应用程序时很容易使用。 让我们看一些适用于 Android 和 iOS 的此类框架的示例。

Robotium 和 ExtSolo (Android)

Robotium 是最早适用于原生和混合 Android 应用程序的测试框架之一。 使用 Robotium 创建的 UI 测试支持 Android 应用程序的功能、系统和用户接受度测试，跨越和处理多个 Android 活动。 事实上，Robotium 从 API 级别 8 开始就为非常早期的 Android 版本提供支持。

最近，Robotium 扩展了 ExtSolo 库，它为应用程序测试提供了各种有用的功能：

• 针对任何显示分辨率自动缩放 x 和 y 点击；
• 多路径拖动；
• 测试失败时自动截屏；
• 模拟位置（GPS 坐标）；
• 更改 Android 设备语言；
• 控制 Wi-Fi 连接；

使用 Java 代码，可以使用任何 Java SDK 和 IDE 轻松构建测试。 此示例中使用的主要函数是findViewById ，它查找由id属性标识的视图。 UI 元素也可以通过名称、类或其他一些属性来标识。 我们的带有id属性的代码示例如下所示：

 solo.clickOnView(solo.findViewById("com.example.app:id/radio0")); solo.clickOnView(solo.findViewById("com.example.app:id/radio1")); solo.clickOnView(solo.findViewById("com.example.app:id/radio2")); solo.enterText((EditText) solo.findViewById("com.example.app:id/editText1"), "Simple Test"); solo.clickOnView(solo.findViewById("com.example.app:id/button1"));

Robotium 在这里尝试根据id 、 description 和其他特征来定位 UI 元素。 不幸的是，这并不总是最好的方法，也不一定适用于 webview 组件。 但是，在 ExtSolo 库的帮助下，用户可以定义随分辨率缩放的 UI 元素上的点击和其他交互。 此外，硬编码坐标是可能的，并且这些坐标会随着显示分辨率的变化而缩放。

如果您使用的是 Robotium，那么开始使用 Robotium ExtSolo 非常容易且不费吹灰之力。 只需为自己克隆存储库并构建库：

 $ git clone https://github.com/bitbar/robotium-extensions $ ant clean instrument

之后，将最近构建的.jar文件放在您的 Android Studio 项目的libs文件夹中，并确保您的项目已链接到它。 所有这些出色的附加功能和服务现在都在您的工作区中。

浓缩咖啡（安卓）

Espresso 测试框架提供 API 用于编写 UI 测试以模拟 Android 应用的用户交互。 Espresso API 是轻量级的，并提供三个主要组件： viewMatchers 、 viewActions和viewAssertions 。

Espresso 的美妙之处在于它提供了测试方法和正在测试的 UI 元素的自动同步。 例如，如果测试脚本想要按下一个按钮，但该按钮在屏幕上还不可见，它会等到该按钮可以被按下（即它是可见的并且可以点击）。 这使得测试执行非常快，因为没有测试脚本需要包含任何睡眠或等待命令。 此外，开发人员不需要额外的逻辑来处理与时序相关的问题。

 // R class ID identifier for radio buttons onView(withId(R.id.radio0)).perform(click()); onView(withId(R.id.radio1)).perform(click()); onView(withId(R.id.radio2)).perform(click()); onView(withId(R.id.EditText1)).perform(click()); // Instead of R, we use getIdentifier onView(withId(getInstrumentation().getTargetContext().getResources() .getIdentifier("com.example.app:id/EditText1", null, null))).perform((typeText("Simple Test"))); onView(withId(getInstrumentation().getTargetContext().getResources() .getIdentifier("com.example.app:id/Button1", null, null))).perform(click());

Espresso 有自己的优点和缺点，并且由于 API 轻量级，开发人员可以使用的附加服务或函数调用并不多。 例如，您必须使用替代方法来截取屏幕截图、管理测试、输出测试结果等。

在 Google IO 2016 上，Google 推出了 Espresso Test Recorder 作为 Android Studio 的一个组成部分。 虽然该功能尚不可用，但绝对值得等待。

XCTest 和 KIF (iOS)

XCTest 与 Xcode 紧密耦合，但仍可用于真实的 iOS 设备和模拟器。 XCTest 允许开发人员为任何级别的组件编写测试，并且还提供了 UI 测试功能的框架。 XCTest 测试分为 XCTestCase 的子类。 使用 XCTest 编写任何测试对于 iOS 开发人员来说都是微不足道的，因为 XCTest 与 Objective-C 和 Swift 完全兼容。

KIF（“keep it functional”的缩写）是一个与 XCTest 测试目标密切相关并使用 XCTest 测试目标的 iOS 集成测试框架。 KIF 测试可以直接在 XCTestCase 或任何子类中执行。 KIF 通过利用操作系统为有视觉障碍的人提供的可访问性属性，可以轻松实现 iOS 应用程序的自动化。

让我们看看我们的 UI 组件在 Objective-C 中的外观：

 - (void)testClicksOnRadioButtons { [tester tapViewWithAccessibilityLabel:@”Radio1”]; [tester tapViewWithAccessibilityLabel:@”Radio2”]; [tester tapViewWithAccessibilityLabel:@”Radio3”]; [tester enterText:@”Simple Test” intoViewWithAccessibilityLabel:@”editText1”]; [tester tapViewWithAccessibilityLabel:@”Answer”]; }

或者，使用 Swift，测试看起来就像这样简单：

 testClicksOnRadioButtons() { let app = XCUIApplication() app.radiobutton[0].tap() app.radiobutton[1].tap() app.radiobutton[2].tap() app.staticTexts[“Simple Test”] app.button[0].tap() }

请注意，此高级伪代码需要额外的代码才能完全发挥作用。 如果您正在寻找有关 XCTest 以及一般使用 Xcode 测试功能的更多信息，Apple 可以满足您的需求。

伯爵灰 (iOS)

就在今年早些时候，谷歌开源了其功能性 iOS 应用程序测试框架，名为 EarlGrey。 在 Google 内部使用时，它与原生 iOS 应用程序（YouTube、Google 日历、Google 照片、Google Play 音乐等）配合得相当好，并引发了一些浓厚的兴趣。 要开始使用 EarlGrey，您需要安装 Xcode 环境和 iOS 开发的基本知识。

EarlGrey 和 Espresso 之间有很多相似之处（是的，两者都是由 Google 开发的），它们的特性使两个框架都能快速运行并执行测试。 与 Espresso 类似，EarlGrey 测试会在尝试与 UI 交互之前自动等待事件（动画、网络请求等）。 这使得编写测试更容易，因为开发人员不需要担心睡眠或等待命令。 此外，代码本身更易于维护，因为它提供了测试步骤的过程描述。

EarlGrey 还包含 GREYMatchers 类中可用的匹配器。 该文档建议使用带有可访问性参数的 UI 元素。 要识别 UI 元素，开发人员可以使用grey_accessibilityID()或grey_accessibilityLabel() 。

 - (void)testBasicSelectionAndAction { [[EarlGrey selectElementWithMatcher::grey_accessibilityID(@"ClickHere")] performAction:grey_tap()]; // Example of long press with EarlGrey matchers - (void)testLongPress { [[EarlGrey selectElementWithMatcher::grey_accessibilityLabel(@"Box")] performAction:grey_longPressWithDuration(0.5f)]; [[EarlGrey selectElementWithMatcher::grey_accessibilityLabel(@"One Long Press")] assertWithMatcher:grey_sufficientlyVisible()]; // Example of multi-select, visible click on items - (void)testCollectionMatchers { id visibleSendButtonMatcher = grey_allOf(grey_accessibilityID(@"Box"), grey_sufficientlyVisible(), nil); [[EarlGrey selectElementWithMatcher:visibleSendButtonMatcher] performAction:grey_tap()]; }

与 XCTest 类似，我们的单选按钮实现并不是那么简单，XCTest 的按钮应该定义为 iOS 支持的 UIElements 以启用点击和用户交互。

结论

我们已经介绍了 React Native 应用程序的基础知识以及如何使用各种方法和框架对其进行测试。 这经常出现，但是功能 UI 级别的移动测试自动化的行业标准将适用于 React Native 应用程序，就像它们适用于任何其他原生应用程序一样。 我们在这里介绍的测试自动化框架广泛用于原生移动应用程序、混合应用程序、移动 Web 以及 React Native 应用程序。

总之，确定构建移动应用程序的编程语言并不重要，因为它不会对可以测试它的测试自动化框架产生任何影响。 正如所讨论的，今天有很多强大的测试自动化框架可用，当包装为 APK 或 IPA 时，React Native 应用程序可以使用这些框架。

你用什么来测试 React Native 应用程序？ 在下面发表评论！