内置索引与外置引擎

(ps: 为了和搜索引擎对应起来，这里就将内置门户改成内置索引。)

所以，再仔细回到上面的问题里。要成为一名可以完成任务的程序员，你就需要不断地构建你的门户网站。我们要学习 Web 开发，我们就需要对整个知识体系有一个好

的理解。不断理解的过程中，我们就不断也添加了新的文档，构建新的索引。每遇到一个新的知识点，我们就开始重新生成新的索引。

然后又会引入一个问题：

人的大脑如同一间空空的阁楼，要有选择地把一些家具装进去。

我们需要不断地整理一些新的技术，并且想方设法地忘记旧的知识。

有时，不得不说笔记和博客是这样一个很好的载体。在未来的某一天，我们可以重新挖掘这些技术，识别技术的旧有缺陷，发展出新的技术——水能载舟，亦能覆舟。

如何编写测试

写测试相比于写代码来说算是一种简单的事。多数时候，我们并不需要考虑复杂的逻辑。我们只需要按照我们的代码逻辑，对代码的行为进行覆盖。

需要注意的是——在不同的团队、工作流里，测试可能是会有不同的工作流程：

• 开发人员写单元测试、集成测试等等
• 测试团队通过界面来做黑盒测试
• 测试人员手动测试来测试功能

在允许的情况下，测试应该由开发人员来编写，并且是由底层开始写测试。为了更好地去测试代码，我们需要了解测试金字塔。

测试金字塔

测试金字塔是由 Mike Cohn 提出的，主要观点是：底层单元测试应多于依赖 GUI 的高层端到端测试。其结构图如下所示：

从结构上来说，上面的金字塔可以分成三部分：

1. 单元测试。

图 47: 测试金字塔

1. 服务测试
2. UI 测试

从图中我们可以发现：单元测试应该要是最多的，也是最底层的。其次才是服务测试，最后才是 UI 测试。大量的单元测试可以保证我们的基础函数是正常、正确工作的。

而服务测试则是一门很有学问的测试，不仅仅只在测试我们自己提供的服务，也会测试我们依赖第三方提供的服务。在测试第三方提供的服务时，这就会变成一件有意思的事

了。除此还有对功能和UI的测试，写这些测试可以减轻测试人员的工作量——毕竟这些工作量转向了开发人员来完成。

单元测试单元测试是针对程序模块（软件设计的最小单位）来进行正确性检验的测试工作。它是应用的最小可测试部件。举个例子来说，下面是一个JavaScript的函数，用

于判断一个变量是否是一个对象：

var isObject = function (obj) { var type = typeof obj;

return type === 'function' || type === 'object' && !!obj;

};

是正常工作的：

it("should be a object", function () { expect(l.isObject([])).toEqual(true);

expect(l.isObject([{}])).toEqual(true);

});

虽然这个测试看上去很简单，但是大量的基本的单元测试可以保证我们调用的函数都是可以正常工作的。这也相当于是我们在建设金字塔时用的石块——如果我们的石块

都是经常测试的，那么我们就不怕金字塔因为石块的损坏而坍塌。

当单元测试达到一定的覆盖率，我们的代码就会变得更健壮。因为我们都需要保证我们的代码都是可测的，也意味着我们代码间的耦合度会降低。我们需要去考虑代码的

长度，越长的代码在测试的时间会变得越困难。这也就是为什么 TDD 会促使我们写出短的代码。如果我们的代码都是有测试的，单元测试可以帮助我们在未来重构我们的代

码。

并且在很多没有文档或者文档不完整的开源项目中，了解这个项目某个函数的用法就是查看他的测试用例。测试用例（Test Case）是为某个特殊目标而编制的一组测试输

入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。这些测试用例可以让我们直观地理解程序程序的 API。

服务测试服务测试顾名思义便是对服务进行测试，而服务可以是有不同的类型，不同层次的测试。如第三方的API服务、我们程序提供的服务，虽然他们他应该在这一个层

级上进行测试，但是对他们的测试会稍有不同。

对于第三方的提供的 API 服务或者其他类似的服务，在这一个层级的测试，我们都不会真实地去测试他们能不能工作——这些依赖性的服务只会在功能测试上进行测试。

在这里的测试，我们只会保证我们的功能代码是可以正常工作的，所以我们会使用一些虚假的API测试数据来进行测试。这一类提供API的Mock Server可以模拟被测系统外

部依赖模块行为的通用服务。我们只要保证我们的功能代码是正常工作的，那么依赖他的服务也会是正常工作的。

而对于我们提供的服务来说，这一类的服务不一定是 API 的服务，还有可能是多个函数组成的功能性服务。当我们在测试这些服务的时候，实际上是在测试这个函数结合

在一起是不是正常的。

一个服务可能依赖于多个函数，因而我们会发现服务测试的数量是少于单元测试的。