测试一直都是Android程序员忽视的重要一环

最新推荐文章于 2022-10-25 23:27:25 发布

郭霖_

最新推荐文章于 2022-10-25 23:27:25 发布

阅读量367

点赞数

原文链接：https://juejin.im/post/5ea298636fb9a03c320bc9a9#heading-7

版权

/ 今日科技快讯 /

近日，谷歌母公司Alphabet发布了截至3月31日的2020年第一季度财报。财报显示，Alphabet第一季度营收为412亿美元，较上年同期的363亿美元增长13%；净利润为68亿美元，较上年同期67亿美元增长3%；每股收益为9.87美元，高于去年同期的9.5美元。财报发布后，Alphabet股价盘后暴涨逾8%。

/ 作者简介 /

明天就是五一小长假了，祝大家玩的开心。另外，听说跨省旅游归来可能会面临隔离，建议大家还是谨慎出行。我们节后再见。

本篇文章转自Flywith24的博客，文章主要分享了他对优达学城资料中关于Android Test相关内容的翻译，希望对大家有所帮助。

Flywith24的博客地址：

https://juejin.im/user/57c7f6870a2b58006b1cfd6c

/ 前言 /

一直以来，关于如何写测试代码的相关内容资源都比较少，之前在优达学城看到了这部分的视频，但由于没有中文字幕，对有些小伙伴可能不太友好。因此我决定将其整理成系列文章，那么就从认识test开始吧。

本文内容来自（需要有账号登录之后才能进行查看）：

https://classroom.udacity.com/courses/ud940/lessons/fa3a54ab-2da2-46b9-af73-e7f05b20f90f/concepts/374e1e3c-7018-4607-97b3-c50e1061ceda

/ 结构 /

作为Android开发者我们知道在Android Studio的Android视图中有三部分代码：

app的逻辑代码（main source set）
androidTest代码
local test代码

test代码知道所有的main source set中的代码，因此可以测试这些类。但是app代码不知道test中的代码，并且androidTest和test都不知道对方的存在。事实上，当你构建出apk并提交应用市场时，测试代码并没有包含在内。

/ 依赖引用 /

下面标记的依赖使用了test的引用方式testImplementation和androidTestImplementation。

注意：这些test代码不会打包到最终的apk文件中。

testImplementation引用的JUnit依赖只能在test source set中使用，这种依赖范围的限制是Gradle实现的。简单总结下：

三种source sets：main，test，androidTest
测试代码能访问app代码
app 代码不能访问测试代码
测试不会被打入到Apk中
依赖范围包括：testImplementation和androidTestImplementation

/ 运行第一个test /

我们打开test source set ，看到其中有一个ExampleUnitTest。

可以看到其内部只有一个addition_isCorrect()方法。有两个要素使它成为一个test：

使用了@Test注解
它存在于两个test source set之一

有了这两个要素，这个方法就可以独立的作为test运行。本示例test测试的内容在第15行，它被称之为断言（assertion）。断言是test的核心内容，它检查你的代码或者app行为是否符合你的预期。本示例中，断言检查 4 是否等于 2 + 2。按照规定，您需要将你的预期结果传入到expected参数中，将实际结果传入到actual参数中。@Test注解和断言语句都是JUnit下的。

关于JUnit的更详细的的信息，请移步官方文档：

https://junit.org/junit4/

让我们开始运行一下这个test，右击该方法，点击Run。

紧接着，Run窗口会出现：

可以看到该窗口显示了test的信息，显示出test是否通过以及有多少test通过。下面我们尝试一个test不通过的情况，我们加入一个断言，如下所示：

这次我们点击Run窗口的绿色按钮来运行test：

我们可以看到，即使只有一个断言失败，整个test失败了。窗口指出了预期的结果为5，而实际的结果为4，并且下边标记处错误发生在第15行，可以看到这的确是个bug。解决好bug ，我们再次运行test 。这次我们使用一个不一样的方式

下面介绍一些其他运行 test 的方式。

可以右击类名选择Run选项：

也可以在左侧视图中右击test source set选择Run按钮，该方法会运行所有test。在顶部可以切换要运行的test ，点击绿色按钮可以运行。也可切换回 app。

/ Android Test VS Test /

下面我们来对比一下androidTest和test：

test	androidTest
Local Tests	Instrumented Tests
Local machine JVM	Real or emulated devices
Faster	Slower

我们来运行一个androidTest，可以看到启动了模拟器：

/ 写一个test /

首先我们针对一个功能来创建test，如图所示，存在一个getForkAndOriginRepoStats()方法用于获取fork仓库和原始仓库的数据并返回StatsResult，其中StatsResult第一个参数为fork项目的百分比，第二个参数为原始项目的百分比。我们调用Generate ，选中test选项，在弹出框中选择JUnit4，点击OK并选择存放在local test中。这样我们就创建了一个test。

接下来我们编写test 。可以看到自动创建出的test路径与app code中的代码路径的包名是对应的。我们先测试项目列表只有一个item，并且没有fork ，然后计算fork项目的百分比和原始项目的百分比。理论上讲，fork项目的百分比为0 ，而原始项目的百分比为100%，代码如下图所示，我们编写完毕后点击运行。

可以看到测试通过这是一个正常流程，我们还需要测试异常的流程，比如repos为empty list或者repos变量本身为null。

可以看到我们的代码中没有针对list为empty或null做判断，所以导致了空指针，之后我们修改代码后即可通过测试。

事实上，我们上面的编码流程叫做Test Driven Development(TDD)。

/ 让你的test更具可读性 /

与写普通代码一样，您需要让您的test代码更具可读性，可以从三个方向入手：

优秀的命名
Given/When/Then
借助断言库

优秀的命名

首先我们来谈谈命名，我们知道test方法使用@Test 注解标记，理论上方法名可以随意命名，但随意的命名会导致可读性的降低，因此需要一些特定的命名规范：测试模块_ 动作或输入_ 结果状态。

例如上面的例子我们的命名为：getForkAndOriginRepoStats_noForked_returnHundredZero。

第一部分显示我们要测试的是getForkAndOriginRepoStats() 方法，第二部分代表我们需要的是没有fork仓库的数据源，第三部分是结果的状态，0%。

Given/When/Then

说完了命名我们来谈谈Given/When/Then。测试的基本结构是Given X，When Y，Then Z。

还是上面的例子

Given 为你的测试逻辑提供数据源
When 是你的实际操作
Then 检查 test 是否通过

借助断言库

上面示例最后的断言代码让人看着很别扭，我们可以借助断言库来提高这部分的可读性。

// 之前
assertEquals(result.forkPercent, 0f)

// 之后
assertThat(result.forkPercent, `is`(0f))

下面的语句就像人类的一句话，翻译下来就是断言forkPercent是0f。这样的写法需要引入一个库Hamcrest。

testImplementation "org.hamcrest:hamcrest-all:1.3"

/ 测试范围 /

测试范围指一个test测试多少代码。例如自动化测试根据测试范围可以分为：

Unit Tests（单元测试）
Integration Tests（集成测试）
End to end Tests（端到端测试）

您的测试策略需要覆盖到所有的类型。

Unit Tests

上面的示例我们已经写过了Unit Tests。

范围是单个方法或类
帮助查明失败原因
应该运行的很快，通常是本地测试
低保真度

他们的范围是单个的方法或类。如果Unit Tests失败了，您知道您的代码在哪里出了问题。因为它聚焦于很小一段代码。Unit Tests也意味着可以快速运行，由于您频繁地修改代码会使得它会频繁的运行，因此需要速度。Unit Tests通常是本地测试。它们有较低的保真度，因为现实世界您的app要执行很多代码而不仅仅是一个方法或者类。Unit Tests就像检查一个链条的每个环节是否能够正常运行。