本期，我们要讨论的话题是 JavaScript 的测试，以检查组件的状态和工作方式是否符合预期，还会介绍一个可以方便编写测试用例的测试方法。这里说的测试当然是使用自动化的测试手段，这是软件质量保证(QA)的重要环节。就本系列文章介绍的 Smart Queue 来说，我们的测试目标包括：

• Task 对象的创建：第二期的代码提供了多种创建方式，需要测试对象创建后的状态。
• Queue 内的任务运行次序：我们提供了两种改变运行次序的方式：优先级和依赖配置，同样也要测试各种配置对次序的影响。

对于第一个目标，只需检查对象创建后的属性是否符合预期即可。我们已经多次提到“符合预期”，断言(Assert)正是为此而设计的。简单的说，断言就是确保所测试的表达式结果为“真”，否则，以某种方式通知测试人员，并帮助其定位断言失败的测试用例。

第二个目标稍稍有点复杂。由于我们在组件编码实现的时候，将排序后的队列(_sorted)隐藏在了闭包中，所以外部是无法访问的。有两种方法可以考虑：(1)重构代码，增加代码的可测试性，又有两种重构方法：(a)设置 debug 开关，打开时将 _sorted 暴露给外部；(b)增加独立文件，以构建的方式拼接代码最终生成一个测试版本。(2)测试行为的结果而不是过程，前一种方法实质上是深入到组件的运行时状态，而这个方法只是检查组件的运行结果。本期选用后一种种测试方式，第一种测试方式留给有兴趣的读者练习:)

需要说明的是，我个人不赞成第一种的方法a. 为什么呢？我先说一下这个任务队列的设计理念：

• 它只是一个队列，只负责“按需”调整任务的运行次序，不关注任务的个体细节。换句话说，它操作整体的任务，而不关心任务具体的行为和表现。
• 它是个安全的队列，使用者（第一期提到的“客户”）可以放心把任务添加进去，不用担心这个任务信息会被其他客户看到。需要说明的是，第二期实现代码中有 SmartQueue.Queue = [[], [], []], 结果是外部可以访问到队列项。代码仅供介绍之用，你可以安全地删除 SmartQueue.Queue = 来达成安全控制。

出处：