使用 Espresso 实现完整覆盖的功能测试(3)

这是我为我们测试平台定义的一个基本测试单位，也是我们整个测试方案里面的一个核心概念。这里有两个方面需要明确一下。

• 有些人会说这是 Espresso 的标准写法，因为你在定义一个 Espresso 测试文件时就必须要指定一个启动的 Activity。但是从官方的 Demo 来看，他们倾向于这个 Activity 仅仅是一个入口，你应该在完成一条完成的测试用例（你可以根据需要跳转到任何页面）以后再进行相应验证。但是在我们的这里，启动的这个页面（可以是 Activity 或者 Fragment）以后就只做当前页面相关的逻辑测试，如果有页面跳转也仅仅是测试是否能成功跳转，不会再对应的界面产生更多的交互。

• 由于 Espresso 是基于 JUnit 实现的，所以你可以针对单个页面编写多个独立得测试用例，它们会以随机的顺序被调用。在我们的单页面测试中，只有单一的测试入口，然后顺序执行这个页面需要执行的所有测试。

在单页面测试中，会根据需求尽可能覆盖这个页面的所有的功能。这个时候有人可能会说，在不同的应用状态下（比如：登录是否），通过 UI 测试所能产生的逻辑并不一致，怎么做到全覆盖能。我们的解决方案是在这个页面的测试代码中，需要全部覆盖该页面所有的逻辑分支，当开始执行这个单页面测试的时候，是怎么样的状态，就进入怎样的逻辑分支。这个时候又有人开始有疑问了，这样怎么做到全功能覆盖呢。想象力丰富的人可能已经想到了解决方案，我们先给到一张图启发一下，后面再介绍我们引入的下一个概念——测试流。

PS：如果使用的 MVP 的模式来编写代码的话，你会发现在单个页面需要那些逻辑是非常清晰的。

虽然上面已经明确定义了单页面测试的写法，但是在实际应用过程中，还是会遇到一些场景，不在定义里面被约束，应该怎么处理会让人产生疑惑，会对单页面测试的能力的覆盖性产生怀疑。下面我列出来的几种情况常见的情况来解释应该怎么坚持单页面测试作为基本单位。

原文转自：http://ohmerhe.com/2017/04/18/espresso_huge_ui_test/