【译】安卓中的自动化测试（1）

博客原地址：【译】安卓中的自动化测试（1）
译文原链接：Introduction to Automated Android Testing – Part 1
翻译：Anthony

我已经看到很多的人对于安卓中如何进行测试感到困惑和不解。在过去，我们会发现在安卓中进行测试不仅困难而且毫无头绪。而这个系列文章将会给你阐述安卓中的测试并将在接下来的几篇文章中逐渐深入进行分析。

为什么需要测试？

下面是我喜欢编写测试用例的一些原因：
- 测试让你换一种思路进行思考并让整个过程中的代码更加整洁。
- 当你的代码测试之后，你会对这段代码代码更有信心。
- 编写测试用例你得到的不仅仅是一个成功通过的绿色状态栏，还可以了解相应代码的覆盖程度。
- 自动化测试中发现了bug会让你的回归测试更加的得心应手。

回归测试对于我来说是编写测试用例的最大益处。如果你重构了代码但是测试依然跑得通，那么你就能确信没有破坏代码的正确性。也就是说你可能当时可能看不到这些益处，直到你在几个月之后的代码重构时才明白当时的测试没有白写。

安卓中有哪些测试。

单元测试

单元测试通常是用于反复的测试代码中的一些最小可能单元（可能是一个方法，类或者组件）的功能性。单元测试用到的常用工具有：
JUnit – 用于测试assertion（断言）
Mockito – 用于模拟非测试类。
PowerMock – 用于模拟静态类，比如AndroidEnvironment

UI 测试 – Instrumentation 测试

UI测试或者说 Instrumentation 测试用于模拟用于和app的交互，点击按钮，在输入框输入文字等操作是一些UI测试能够完成的功能。
用于UI测试的工具有：

• Espresso – 用于app内的测试，选择item，确保可见性。
• UIAutomator – 用于不同app之间的交互。
• 除此之外还有 Robotium, Appium, Calabash, Robolectric 等。

为什么我需要自动化测试？

为了进行自动化测试，首先你应当遵从一些帮助你易于测试的架构模式从而将app构建为整洁易于测试的。一些易于测试的模式有Model View Presenter (MVP) 对于视图层的测试，以及 Repository Pattern 对于网络和数据库层的测试。当然还有很多其他的很多架构可以运用起来。
如果没有一个合理的架构，你可能会发现测试时无用的或者根本不知道如何下手，UI测试也是不可靠的。希望这一系列文章能够解决这个问题。

构建便于测试的app

下面的这张图是我会在系列博客中使用的app架构图。

Views  – Activities和Fragments.只与Presenter进行交互。
Presenters – 用于处理业务逻辑并控制视图展示。Presenters 直接和Respositories 交互获取数据并且将数据转达给视图View层。需要注意的是应当避免使用Android平台相关代码，因为那将会让你的测试更加的困难。
Repositories – 处理从不同数据源获取数据，本地或者网络？ Respositories同Presenter进行交互。
Models – 通用的java对象（POJO），用于Presenter向View层传递数据。

单元测试将会测试Presenters和Respositories，UI测试将会从View层测试一直到Respositories。
有许多描述MVP和架构的文章，可以点击这里, 这里 和这里.
（这里推荐译者整理的文章Android架构合集）

自动化测试放在android app的那个地方？

在你的app 结构目录中，有两个文件夹用于测试代码的放置，分别是 test 和androidTest。

androidTest文件夹 -android Instrumentation 测试放置在这里，这些测试需要在模拟器或者真机上运行。

test文件夹-单元测试被放置在这个文件夹下面。单元测试运行在JVM上面并不需要运行在真机或者模拟器上面。这也就意味着他们对Android的类（比如说Context 类）没有访问权限。既然我们已经明白了如何放置不同的类，以及不同的测试。那么下一篇文章我们会继续深入的讲解如何架构一个易于测试的app。
安卓中的自动化测试（2）链接地址

参考链接

Android 手机自动化测试工具有哪几种？