前端测试：Part1 （介绍）

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

By Gil Tayar

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

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

因此我决定写一篇。这是这一系列文章的第一篇，你能够经过下面的连接找到其余的。

• 介绍
• 单元测试
• E2E测试
• 集成测试

为了这篇文章，我还写了一个小应用-计算器。我会借此向你展现不一样种类的测试。在这里你能够找到源码。

啥是测试

测试，按照个人定义是检查你应用代码是否可以按照预期运行的代码。一些人会把这个叫作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测试。最后咱们会套路测试策略——每一个测试你应该写多少和一些其余须要考虑的事情。

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