阅读 352

前端测试:Part1 (介绍)

原文:Testing Your Frontend Code : Part I (Introduction)

By Gil Tayar

不久前,我的一个朋友开始入坑前端,问我如何测试他写的应用。在电话上,我告诉她我很难在电话上讲清楚,因为这方面要学的东西太多了。我答应她会发给他一些文章来指导她。

当我打开电脑搜索了一下,我发现了太多的文章,并且对这些文章的深度很不满意。我没有发现一些真正有助于理解的文章(从新人的角度来看)。我没有发现一个以前端测试为中心,既有理论又有实践的文章。

所以我决定写一篇。这是这一系列文章的第一篇,你可以通过下面的链接找到其他的。

为了这篇文章,我还写了一个小应用-计算器。我会借此向你展示不同种类的测试。在这里你可以找到源码。

啥是测试

测试,按照我的定义是检查你应用代码是否能够按照预期运行的代码。一些人会把这个叫做TDD,但是TDD(Test-Driven Development or Test-Driven Design)只是测试的一种流派,是指先写测试用例,然后实现业务逻辑。

坦白讲,我不认为先写还是后写测试用例有啥关系,只要你写了足够多的测试让你觉得你的线上代码没问题就行了。但是有的人认为这很重要,所以我这里也提一嘴。

遗憾的是,业界内部充斥着TDD的思想,以至于在业务代码旁边写用例的行为都没有一个标准的术语去称呼。我就叫他开发者测试或者仅仅是纯测试吧。你可以看下这个,但我建议你看完我的这个系列的文章后再去看。

为啥要测试

不,我不是想要讲为啥要测试,你要是不想测就不测。但是你会对你写的应用一遍遍地重复手动测试,这太恶心了。想想那些诡异的bug,即使你修复了,仍然会在午夜梦回的时候萦绕在你心头。上线变成了一个充满不确定性和恐惧的工作。

我仍然不会讲为啥要测试。

测试的类型

对于学习测试的新手来说,不同的测试类型也会让人感到困惑。如果你对此做过调研,你可能已经听过(这里给出一个不完全的列表):单元测试、接受度测试、集成测试、端到端测试、组件测试和服务测试。

更糟的事,当有人在谈起其中一个术语时,他对此的定义可能会和另一个人不太一样。

再说一遍,我对起名这件事从来都不在意。我认为测试的类型从来就没有一个死标准。但我认为所有的测试都在一个区间内部,这个区间一头是单元测试,另一头是端到端测试(简写为E2E 测试)。

测试区间

我们以最简单的测试类型——单元测试讲起。单元测试,顾名思义,就是测试一个单元的代码。但是啥事一个单元呢?这取决你用的语言。它可以是一个函数、模块、包、类,甚至是对象(对于JavaScript和Scala来说)。在JavaScript中,通常是一个类或者模块(对于npm/CommonJS来说模块就是一个文件)。

单元测试最重要的事这些单元是相互隔离的。所以单测很适合测试算法、函数(比如一个计算字符串中包含多少个字符的函数)或者包含多个方法的类。

这些模块都很适合拆分测试,因为他们不大容易相互依赖。但是加入我要测试的单元依赖另一个单元呢?我们有两条路可走:两个一起测,或者去mock另一个。

如果我们把两个单元一起测,那它还是单元测试吗?这就是测试区间的问题了。那些纯粹主义者会说,这就不是单测了。我会说,我压根就不在乎。我倾向于叫它单元测试,但是如果有人叫它集成测试,或者双元测试,我也表示OK。

mock是啥意思呢?我们举个栗子:

exports.writeSumToFile = (a, b, fileSumWriter) => {
  const sum = a + b

  fileSumWriter(sum)
}
复制代码

这个(显然是强行人造例子)单元是一个模块,包含一个writeSumToFile函数,接受两个数字类型的参数,并把它们的和写入一个文件中。

但是注意,这个函数并不负责写文件,它使用了另一个单元(fileSumWriter)去完成写文件。

为了测试这个单元,我们既可以把真正的fileSunmWriter传进去,或者mock一下这个函数的实现,也就是说在测试的时候并不会写文件。

但我们传入函数的mock实现时,这个测试就绝对是个单元测试了(即使从最严苛的角度看)。但是如果我们把两个单元放一起测,很多人就会说这不是个单测。

我不在乎怎么叫它。

所以在这一段,我们有测试一个单元的代码。在另一端,我们有E2E测试——对整个应用的测试。E2E会测试所有的东西,测试对象就是你要上线的代码。

这就是测试区间的两端。大部分测试都位于这二者之间——它们逐渐增加测试的范围,越来越多的代码会被测试到,越来越少的代码被mock。

有些人把这些处于中间的额测试称为“集成测试”。但是对于那些TDD信徒,集成测试是不一样的,我们后来会说到。我将会不严谨地把那些比单测多但又不覆盖全部的测试称作——集成测试。

那你应该如何分配你的测试比重呢?多数人认为,存在一个测试金字塔。单测最多,集成测试要少得多,E2E测试最少。我们把这个讨论留在这个系列的末尾,因为这些文章的重点是要如何做单元测试、集成测试和E2E测试。最后我们会套路测试策略——每个测试你应该写多少和一些其他需要考虑的事情。

敬请期待下周的第二部分,我会在那儿讨论单元测试。