用于React Native应用的不同的自动化测试框架

blueswan 发布于1年前 阅读14435次
0 条评论

在当前,移动端应用的壁垒越来越高。首先,应用必须要满足各个应用市场所期望的质量标准;其次,移动应用的用户对产品的要求也是非常高的。由于越来越多的同类应用可以下载,所以用户完全不能够容忍一个有问题的应用。同时,移动应用现在已经是人们日常生活中一个非常重要的部分,他们完全不会吝啬于表达对一个应用的爱和恨,在数秒之间就可以得到来自于数百万用户的反馈。

扩展阅读

当前的移动应用比以往任何一个时候都要更加重要 ,但是同时也是一项非常困难的有挑战性的任务,比如:开发一个恰到好处的应用,其可以在所有可能的设备(不同OS版本、屏幕尺寸、芯片和其他硬件特征)运行良好同时获得流畅的用户体验。

用于React Native应用的不同的自动化测试框架

增长的移动平台和设备碎片 ( 查看大图 )

当前有太多的技术、工具、框架和开源组件可以被用来构建原生移动应用,但是React Native能够为此场景带来什么样的价值,以及它如何能够确保基于其开发出来的应用被目标用户所接受?

本文主要介绍在 测试React Native应用 中,什么是可用的。首先,本文在介绍如何进行测试之前解释了React Native的一些关键特征;其次,本文从单元、集成、功能测试三个角度对测试方法和框架进行分类,并为每一类提供了实例;最后,本文就如何使用流行的开源自动化测试框架来对功能型应用进行测试提供了一些简单实例。

React Native应用的基本结构

所有的这一切都开始于三年前Facebook将其自己的框架React开源给web开发者。React终将是会流行起来的,不仅仅是因为它是由Facebook开发,而是因为其给予web开发者的能力,尤其是它改变了我们构建应用的方式。

事实上,“learn once, write anywhere”类型框架也不是一个新的概念了,我们已经有许多JavaScript库(如 Sencha , PhoneGap and Appcelerator , among others)来做相似的事情了,但是React对开发者的影响更大一些,主要体现在对开发者习惯的影响和使开发者思考如何将一个应用UI拆分为具体的组件。

React Native 并不会使用DOM渲染,相反,它使用原生的UI视图来进行渲染,这就意味着你可以使用操作系统提供的原生组件。这种使用声明式的API来替代原来的DOM API的产品工作流给了开发者一种 更加内聚的和简化的抽象水平 .

用于React Native应用的不同的自动化测试框架

React Native在Android和iOS上的开发流 (图片: Testdroid ) ( 查看大图 )

React Native的关键性技术在于将 React programming model 引入了移动应用的开发和测试。确切的说,它并不是被直接当作一种跨平台的工具或者框架来使用,但是它加速了在这个新的平台上构建移动应用的趋势,这同时也是使得React Native如此强大并且容易在这个新的平台上学习和工作的基石之一。

原生移动应用与web应用的最大的不同(同时也是优势)之处在于。原生移动应用不是在浏览器端运行一个基于JavaScript的实现同时暴露HTML元素,而是依赖于 应用中嵌入的JavaScript内核 ,其可以获得特定平台的UI元素。

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

所有的移动软件都是采用成分(译者注:可以理解为组件或者控件)构建起来的。在 Android and iOS 中可以这样理解:小的软件组件通过组合来形成更大的更高级别的功能性更强的组件,直到满足整个应用的目标和需求。一个好的测试方案是运行可以覆盖所有层次功能的测试用例。

在本文中,我们将在三个层次来介绍测试方法和自动化框架。最基本的关注点在最高的层次,即功能性测试,但是React Native应用也能够至少在以下级别进行测试,而且是自动化测试:

  • 单元测试

单元测试可以看作是和在组件级别测试JavaScript对象和方法一样的最基本的。

  • 组件测试

每个组件都可以在视觉上或者功能上被测试。 ReactTestUtils 提供了一个用于测试React组件的简易框架。

  • 集成测试

接下来是集成测试。集成测试是一组不同的单元被当作一个整体来进行测试的阶段。

  • 功能测试

功能测试是一种黑盒测试的类型,其主要关注于用户需求和交互。功能测试会从整体上覆盖所有的底层软件,所有的用户交互和应用。

除了 ReactTestUtils ,React Native也提供了很有用的 单元测试方法 ,但是这些方法还没有一个可以完全覆盖应用程序的实际逻辑,因此,基于React Native构建的移动应用可以更多的获益于功能性UI测试。 许多功能性的自动化测试框架 都是可以使用的,在本文中我们只涉及最流行的几个。

虽然单元测试能够在组建级进行,但是在React Native应用中,功能性自动化测试为应用整体提供了更好的能力。使用React Native,组件的逻辑单元测试可以被分开进行,其使用传统的JavaScript库同时强制让React Native返回规则的组件而不是原生组件。使用功能性的自动化测试框架,UI元素是整个应用的一部分,同时也可以很容易当作一个整体来进行测试。

如下图所示:本文将这些框架分为和

用于React Native应用的不同的自动化测试框架

可用于React Native应用的不同的自动化测试选项. (图源: Testdroid ) ( 查看大图 )

React Native应用最好的部分是:对于所有主要的移动平台(Android和iOS)它都是完全原生的,这就意味着我们可以根据测试目标来获得更多的框架、工具和原生方法。在接下来题目为“在React Native应用中使用功能性的自动化测试框架”的部分我们将介绍功能性的自动化测试框架。

接下来我们从 unit-testing capabilities 开始介绍,使用一个JavaScript测试来说明。

使用Jest和Jasmine进行单元测试

默认情况下,React Native提供在Android和iOS都可以使用的 Jest 来进行单元测试。现在,测试的覆盖率并不完美,但是根据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组件。为了实现可定制化的集成测试,两个工具 RCTestRunnerRCTestModule 可以被用来使用。

用于iOS应用的测试架构的基本Objecttive-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测试框架,同时它还提供了行为驱动开发(BDD)、测试驱动开发(TDD)和用于测试的QUnit接口。

在功能性UI测试中,本文将涉及到一些最出名的同时也是使用最广泛的自动化测试框架,包括Appium、Calabash、XCTest等。

在React Native应用中使用功能性的自动化测试框架

为了使应用开发流程合理化同时最大化测试覆盖率,我们有很多的开源自动化测试框架可以选择。

如果你的应用将运行在一些OS平台上,那么最佳选择是所选测试框架需要能够支持多平台并且提供自动化测试的强大基础(译者注:即)。在移动端,所谓的跨平台指的是一个框架在Android和iOS上提供着同样的API、工具和性能。

另外,同样还有很多也是可选的。本质上,每一种框架都是为特定某一个平台而构建的,但是在大多数情况下它也是非常容易被适配到其他平台的。除了Appium和Calabasn,在本文中我将涉及四个特定平台的框架,分别是:Robotium、Espresso for Android、XCTest和EarlGrey for iOS。

用于React Native应用的不同的自动化测试框架

用于功能性UI测试的不同的自动化测试框架 (图源: Testdroid ) ( 查看大图 )

当提到自动化测试,需要牢记的是使用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应用进行交互.鉴于此,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服务器指令的服务器和监听器。这一点和Selecium是相同的,Selecium是从 Selecium客户端库来获得HTTP请求 。Android和iOS之间不同之处如下图所示:

用于React Native应用的不同的自动化测试框架

Appium是如何运行于Android和iOS上的 (图源: Testdroid ) ( 查看大图 )

在iOS中,Selecium WebDriver可以从Appium脚本中获得一个指令(例如: click() )然后通过 向Appium服务器发送要给HTTP请求 来将指令发送到JSON表单中。Appium识别整个自动化上下文然后发送这个指令到工具指令服务器中,然后就等待工具指令客户端来选择它并在iOS工具环境中使用 bootstrap.js 执行它。一旦这个指令被执行,工具指令客户端便会给Appium服务器返回信息,这就在控制台中记录了所有与该指令有关的日志信息等。

在Android上,除了 使用Selendroid和UniAutomator框架 的话,其他所有工作都是同样的步骤。简而言之,Appium将WebDriver指令翻译为UiAutomator指令(API level 17或者以上)或者Selendroid指令(API level 16或者以下)。在物理设备上, bootstrap.jar 发起一个从TCP客户端获取指令的TCP服务器。在ios上整个过程也是相似的。

如果你对开始使用Appium感兴趣,许多资料都是可用的,包括 手把手指导Appium教程

Calabash

另一个非常好的跨平台测试框架是 Calabash ,它可以使任何人为移动应用写测试。主要的不同之处在于Calabash测试是在 Cucumber 进行编写。使用这类语言来测试的背后的想法是令人惊叹的:测试本身就像是一个规范,同时所有的测试还是简单易读的同时还可以被自动化系统执行。

与Appium相比,Calabash提供了一套更简单的方式来创建Android和iOS的跨平台测试。由于这种简单词汇和规范为导向的语言使得Calabash测试在所有的平台都是相同的。实际中的测试是在 Gherkin 中编写、在Cucumber上运行。

由于上述的这些能力,Calabash在 AndroidiOS 应用上的差异是非常小的。此外,由于所有的组件和用户接口对这些平台都是完全原生的,所以对于React Native应用来说没有意义。

用于React Native应用的不同的自动化测试框架

Calabash on Android and iOS. (图源: Testdroid ) ( 查看大图 )

但是基本的测试和创建测试流都是维持相同的。Calabash测试包括特征、场景和步骤,推荐的过程是首先完成最高级别的描述:特征,紧接着是场景,然后是实际步骤。一个很好的经验法则是首先创建 Calabash特征

用于React Native应用的不同的自动化测试框架

Calabash的特征、脚本和步骤 (图片: Testdroid ) ( 查看大图 )

下边的例子说明了我们的应用和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,仅仅需要在控制台中输入下边几行代码Calabash就可以很快被安装。

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

这段代码负责安装Calabash-Android和Calabash-iOS,然后你的自动化测试之旅就可以开始啦。

特定平台框架

当提到Android和iOS应用的自动化测试时,使用特定平台框架比跨平台框架有一些优势,比如,一些 框架被构建的非常贴近于SDKs和IDEs ,它们在应用程序被开发的时候就可以使用。接下来看一下这类型框架用于Android和ios中的例子。

Robotium和ExtSolo(Android)

Robotium 是用于原生和混合Android应用开发的第一批测试框架之一。使用Robotium创建的UI测试可以对Android应用进行跨越和操作多个Android活动的功能、系统和用户接收测试。实际上,Robotium从早期的API 8版本就开始支持了。

最近,Robotium被提供更多有用功能测试的 ExtSolo库 扩展。

  • 任何显示分辨率下的x和y的点击自动缩放;

  • 多路径拖拽;

  • 在测试失败的时候自动屏幕截图;

  • 模拟定位(GPS坐标);

  • Android设备语言的更改;

  • Wi-Fi连接的控制;

由于使用Java,所以测试可以很容易的使用Java SDK和IDE进行构建。在这个例子中最基本的函数就是 findViewById ,这个函数查找使用 id 属性来标识的视图。UI元素可以使用 name 、 class 或者其他属性来进行标识。使用 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 、描述和其他特征去尝试定位UI元素。不幸的是,这并不总是最好的方式而且在webview组件中也未必可以使用。但是,借助于ExtSolo库,用户可以在随分辨率缩放的UI元素上定义点击和其他交互。而且,硬编码坐标也是可能的,它们可以在显示分辨率更改的时候进行缩放。

如果你正在使用Robotium,那么开始使用Robotium ExtSolo是容易且不费力的,仅仅需要将仓库复制为你自己的然后构建库:

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

然后将最近构建的 .jar 文件放在你安卓工作目录的 libs 文件夹下同时确保你的工程是和它链在一起的。此时,所有的额外功能和服务都已经存在于你的工作空间了。

Espresso (Android)

Espresso 测试框架提供API,这些API在安卓应用中用于模拟用户接口的UI测试。 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当作Android Studio中一个集成的部分来介绍。尽管很多功能还不可用,但是它也值得无限期待。

XCTest 和 KIF (iOS)

XCTest 紧耦合于Xcode,但是它在真实的iOS设备或者模拟器上边都是可用的。XCTest允许开发者编写任何级别的组件测试,同时也提供了一个具有UI测试能力的框架。XCTest测试类属于 XCTestCase 的子类。对于iOS开发者来说,使用XCTest编写任何测试都是很容易的,因为XCTest对于Objective-C和Swift都是完全兼容的。

KIF (“keep it functional”的简称)是一个iOS集成测试框架,该框架和XCTest紧密相关同时也与XCTest测试目标相同。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有你想要的 .

EarlGrey (iOS)

就在今年的早些时候, 谷歌开源了 它的功能性iOS应用测试框架,命名为EarlGrey。在谷歌内部使用中,它已经在原生iOS应用(YouTube, Google Calendar, Google Photos, Google Play Music等)上已经运行的相对良好同时也引发了很大的兴趣。为了 开始使用EarlGrey ,你需要安装Xcode环境和具备iOS开发知识。

EarlGrey和Espresso(没错,都是由谷歌开发)有很多相似之处,它们的特性使得两个框架都快速的运行和执行测试。与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支持的UI元素。

结论

我们已经覆盖到了React Native应用的基础,同时展示了它们是如何采用不同的方法和框架进行测试的。所有的都会变化的很快,但是在功能性UI级别的移动自动化测试的行业标准将会在React Native上起作用,就像它们在其他原生应用上的作用一样。我们所覆盖到的自动化测试框架已经广泛应用于原生移动应用、混合应用、移动web和React Native应用中。

总之,决定构建移动应用的编程语言是没什么的,因为它们对自动化测试框架是没有任何影响的(译者注:编程语言的选择不会对测试造成任何影响)。正如上述讨论的,很多功能强大的自动化测试框架如今都是可用的了,打包为一个APK或者IPA时React Native应用将和它们一起运行。

你正在使用什么工具来进行React Native的测试呢?在下边提出评论吧。

查看原文:用于React Native应用的不同的自动化测试框架

需要 登录 后回复方可回复, 如果你还没有账号你可以 注册 一个帐号。