测试

简介

测试使你可以确保应用按你的方式工作，特别是当你的代码随时间变化时。如果你拥有良好的测试，你可以自信地重构与重写代码。测试也是对于预期的行为最具体的文档，当其他开发者阅读测试时可以理解如何使用你的代码。

自动化的测试是极为重要的，因为它可以运行一个更大的测试集远多于你手动可以做的，从而使你立即捕捉到错误。

整本书都是以测试为主题进行编写的，所以我们可以在这里轻松地接触到一些基本的测试。重要的是，当我们编写测试时，你要测试应用的那一部分，以及你如何验证这样的行为是否正常工作。

单元测试：如果你想测试应用中的某个小模块，你可以编写一个单元测试。你需要stub及mock其他的模块，以此作为常用的手段来隔离每个测试。通常你也需要去做一下spy，来验证模块中的单元测试是否存在。
集成测试：如果你正在测试多个模块正确的协同运作，你将编写一个集成测试。这些测试非常的复杂且需要运行客户端及服务端的代码用来验证跨越两者的沟通是否如逾期般的工作。通常一个集成测试将仍隔离完整应用中的一部分并在代码中直接验证结果。
验收测试：如果你想去编写一个测试，执行应用的任何可运行版本以及验证在浏览器中点击正确的按钮发生正确的事，那就需要去写一个验收测试（有时也被成为“端到端测试”）。这样的测试通常会试图尽可能少的在应用中建立钩子，除了为执行测试设置的正确数据之外。
负载测试：最终你或许期望去测试你的应用在典型负载下工作，或者在它宕机能承受多大的负载。这成为负载测试或压力测试。这样的测试并不会经常执行且对配置非常具有挑战性，但对于我们发布一个较大产品的信心是非常重要的。

在大多数情况下，测试一个Meteor应用是不异于测试任何其他全栈JavaScript引用的。然而，对比大多数传统后端框架和专注前端的框架，有两个因素将为测试Meteor应用带来一些小小的挑战：

客户端和服务端的数据：Meteor的数据系统使其轻松地跨越客户端与服务端的间隙，往往使你在建立应用时忘却数据的流转。它将成为测试你的代码在间隙间是否实际的正确工作的阻碍。在传统框架中，你花费大量时间思考客户端与服务端的连接，但Meteor的全应用测试模式使其简单地编写覆盖全栈的集成测试。另一个挑战是创建的在客户端上下文中的测试数据；我们将在下文的生成测试数据章节中讨论实现方式。
响应性：Meteor的响应性系统是“最终一致”的，当你针对系统做了一次响应式的输入时，你将在随后看到用户界面的反应。这可能是对于测试的一个挑战，但这里有一些方法等待那些变化发生来验证结果，例如Tracker.afterFlush()。