本书介绍

JavaScript专业开发人员必须具备的一个技能是能够编写可测试的代码。不管是创建新应用程序，还是重写遗留代码，本书都将向你展示如何为客户端和服务器编写和维护可测试的JavaScript代码。

从减少代码复杂性的方法，到单元测试、代码覆盖率、调试、以及自动化，您将全面学到如何编写让你和你同事能够轻松修复和维护的JavaScript代码。测试JavaScript代码是一个复杂的过程。本书将在很大程度上帮你简化该过程。

目标读者

本书主要目标受众是那些想成为JavaScript专业开发人员的人。初中级水平、或者专家级别的开发人员都适合阅读本书。因为每个人都可以从本书获取有用的知识。

JavaScript可能不是我们所使用的唯一语言，但在编写或测试程序时要用到大量JavaScript。如果有人付费让你编写JavaScript代码，如果你每天都用JavaScript编写不同大小项目的话，本书正是你的不二选择。

如果你加入了一个必须要测试JavaScript的QA或工具团队，本书也适合您阅读——第3章到第7章非常值得一读。本书的目的是使测试尽可能容易，进而全部自动化。希望这本书能使大家的工作更轻松。这就是我要达到的目的。

如果你编写JavaScript不太多，这本书仍会为你提供很多有用的信息——特别是复杂度（第2章）、基于事件的架构（第3章）、以及调试（第7章）的这些章节。注意，其余章节也有很多有用的信息，但它们可能不会直接解决你的问题。我遇到的众多难题促使我撰写了这本书——我从之前的错误和努力工作中学到了很多，所以你也应该这样！从头开始养成好习惯，将会让你更富有成效和快乐。

非目标读者

遗憾的是，本书并不是适合所有的人。如果你有兴趣学习JavaScript，建议先从其它地方学习一些该语言的基本知识，然后再回到本书。如果你已经能够编写整洁、零bug的代码，且这些代码有充分的文档和注释，能够自动化构建、且连续运行所有单元测试和集成测试、能够生成完整的代码覆盖率（code coverage）报告、自动部署到生成环境，这样的话，本书对你可能就没多大用途了。如果不得不进行代码调试的话，可以快速看一下第7章，或者可以看一下第6章，了解一些小技巧。

如果你不经常用JavaScript，现在就可以合上本书了。

内容简介

本书将在几个步骤内解决如何编写可测试的代码。首先，我们将研究复杂度（complexity）。接着看架构选择，其会限制复杂度和耦合度（coupling）。以此作为基础，在功能层面和应用程序层面上继续测试方面的内容。我们将全面了解代码覆盖率和调试（debugging），然后完成自动化相关的所有内容。在本书最后，大家将更全面理解“什么是”以及“如何进行”可测试的JavaScript。

第1章可测试的JavaScript

本书的最重要主题是编写和维护“可测试”的代码。但可测试的代码是什么？为什么要努力编写它？如何进行编写？我们将从研究这些问题开始，并且了解一些流行的开发理论以及它们和可测试代码之间有何联系。最后，不管是是否跟着进行实战，编写可测试代码的关键都在于让代码保持短小、整洁、简单、松耦合。

第2章复杂度

复杂度是很多问题的根源，不仅仅是可测试性。这些问题包括可理解性和可维护性，这两个因素是代码质量的关键指标。一些系统和应用程序本质上是复杂的，事实上，大多数应用程序都是很复杂的，但在处理和表达这些复杂性时，有正确的方式也有错误的方式。很显然，将复杂的部分分解成一个个更小、更简单的小块是首要步骤。降低耦合度和扇出（fan-out）是管理复杂度的另外两种方式。在探索可测试的JavaScript时，我们会研究所有这些方法，甚至更多内容。

第3章基于事件的架构

讨论复杂度之后，我们将深入研究基于事件的架构。该应用程序架构可以极大地降低复杂度和耦合度，同时提供简单的方式将应用程序分解成更小、更自足的片段。不管应用程序是用于服务器端还是客户端，或者（很可能）用于两者，基于事件的架构均可以解决第2章中列举的很多问题。即便该架构不适合作为所有应用程序的总体架构，在整体架构中肯定也会有用到基于事件架构的概念和实践的地方。

第4章单元测试

关于单元测试有很多争论。测试到底有多重要？单元测试并不能发现所有的错误。像其他工具一样，单元测试是可测试性的其中一部分。描述代码为“可测试”的，并不意味着这些代码的测试用例是可用的；而是说为这些代码编写测试用例比较简单而已。单元测试是特殊的测试，因为通常它们是测试开发人员唯一要编写的。它们具有侵入性，要求测试代码和程序代码隔离，并且可以独立于应用程序运行。这可能会使单元测试变得有难度，因为在隔离环境下独立运行测试代码是非常困难的。本书很大一部分章节都是讲解如何确保代码能够隔离运行，从而使编写单元测试变得更简单。单元测试无法发现所有的Bug（甚至大多数bug），但它们所找到的Bug验证了运行单元测试确实是值得的。同样重要的是，测试代码要遵循和即将测试的应用程序代码一样的高标准和高原则。

第5章代码覆盖率

代码覆盖率通常与单元测试有关。代码覆盖率是单元测试的一个很好的衡量标准；然而，我们会发现这并非总是如此。代码覆盖率不仅仅适用于单元测试！所有类型的测试，包括集成测试、手工测试、性能测试，都可以受益于代码覆盖率。我们将研究代码覆盖率的优势和劣势，以及如何生成、查看代码覆盖率、并使其变得有意义。

第6章集成测试、性能测试、负载测试

当然，除了单元测试以外，还有很多其他类型的测试。集成测试、手工测试、性能测试、功能测试以及其他类型的测试，在寻找和挖掘Bug的工作中，都发挥着很重要的作用。不管谁做这些测试工作——开发人员、QA团队，甚或是不知情的用户，不管你喜欢不喜欢，都要完成这些类型的测试。将应用程序作为一个整体进行轻松测试的能力也是至关重要的。模块化功能使测试代码能够与实现的功能更密切相关，这有助于开发人员更快地修复bug。在这些测试中使用代码覆盖可以快速显示黑盒测试期间执行的代码。大量的基于JavaScript的工具可以让开发人员用于集成测试和性能测试，我们将深入研究其中一些工具，给大家一个直观的展现。

第7章调试

我们编写的代码，第一次编写时不管看起来多完美，都是不完美的。我们的代码肯定会产生Bug，可能有很多的Bug。我们想到的和意想不到的Bug都有可能会破坏代码。我们的测试、其他人的测试、或者用户使用程序时都有可能发现Bug。测试时发现的Bug是最容易解决的，这也是最大化测试的一个很好的理由。用户运行程序时发现的Bug更难以追踪，其结果是，不仅要调试自己的代码，还得调试别人的代码。针对Node.js和浏览器代码这两方面，我将分享一些调试的技巧和窍门。要准备一个好用的调试环境，因为我们要经常用到它。

第8章自动化

最后，对于测试，一遍遍地手工操作不仅不可持续，而且非常无趣。软件编程是世界上手工处理过程最多的工作之一，但测试和软件维护却不一定。运行测试、生成代码覆盖率报告、执行静态分析、精简和压缩代码、以及向生产环境或其他环境上部署或回滚代码都应该是自动化过程的一部分。自动化可以确保不管发生什么情况，无论是成功还是失败，它会很快地进行处理，更重要的是在某种程度上可以重复操作。程序代码错了，自动化测试就会失败、生产环境运行也会失败、其他事情也会出错，但这些绝对不会关联到我们的程序代码。这就是现实。关键是要从这些失败（连同你造成的故障）中尽快且不着痕迹地恢复回来。

小结

编写可测试的代码会让我们的工作，以及我们手下那些人的工作，变得非常简单。从更少的Bug到更多容易修复的Bug、从容易测试到简单调试，编写可测试的JavaScript是明智之选。

本书将展示通往睿智道路的途径。阅读整本书之后，大家将对编写和维护可测试的JavaScript实际需要方面有一个很好的了解。但这仅仅是一个开始。我们作为开发人员，必须将这些实践和模式应用到日常工作中。必须抵制住“懒惰”且不编写测试的诱惑，避免走回头路，防止自己或别人来收拾我们的烂摊子。可测试的JavaScript代码将会延续。如果你现在正在编写遗留代码，帮你自己和老板一个忙，开始编写可测试的代码。希望你会发现，这样做并不是很难，而且非常有益、甚至非常有趣！