新书《编写可测试的JavaScript代码 》出版，感谢支持

本书介绍

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代码将会延续。若是你如今正在编写遗留代码，帮你本身和老板一个忙，开始编写可测试的代码。但愿你会发现，这样作并非很难，并且很是有益、甚至很是有趣！