10、测试
测试包含单元测试、性能测试、安全测试和功能测试等几个方面，本章将从Node实践的角度来介绍单元测试和性能测试。
10.1 单元测试
10.1.1 单元测试的意义
开发者自测。对于开发者而言，不仅要编写单元测试，还应当编写可测试代码。
编写可测试代码原则：
- 单一职责
- 接口抽象
- 层次分离
10.1.2 单元测试介绍
1.断言
2.测试框架
3.测试代码的文件组织
4.测试用例
5.测试覆盖率
6.mock
7.私有方法的测试
10.1.3 工程化与自动化
1.工程化
2.持续集成
10.1.4 小结
在这一节中，我们介绍了普通的单元测试的方方面面，对于一些特定场景下的单元测试方式并未做过多介绍比如测试Web应用等,读者可以自行查看所用Web框架的测试方式,比如Connect或Express提供了supertest辅助库来简化单元测试的编写。
在项目中经常会因为依赖方的变化而产生业务代码的跟随变动，如果没有单元测试的覆盖，依赖方逻辑发生变化后，很难定位该变动影响的范围。一旦为项目覆盖完善的单元测试项目的状态将会因为测试报告而了然于心。完善的单元测试在一定程度上也昭示着项目的成熟度。
10.2 性能测试
单元测试主要用于检测代码的行为是否符合预期。在完成代码的行为检测后，还需要对已有代码的性能作出评估，检测已有功能是否能满足生产环境的性能要求，能否承担实际业务带来的压力。换句话说，性能也是功能。
性能测试的范畴比较广泛，包括负载测试、压力测试和基准测试等。由于这部分内容并非Node特有，为了收敛范畴，这里将只会简单介绍下基准测试。
除了基准测试，这里还将介绍如何对Web应用进行网络层面的性能测试和业务指标的换算。
10.2.1 基准测试
10.2.2 压力测试
10.2.3 基准测试驱动开发
- 写基准测试
- 写/改代码
- 收集数据
- 找出问题
- 回倒第2步
10.2.4 测试数据与业务数据的转换
10.3 总结
测试是应用或者系统最重要的质量保证手段。有单元测试实践的项目，必然对代码的粒度和层次都掌握得较好。单元测试能够保证项目每个局部的正确性，也能够在项目迭代过程中很好地监督和反馈迭代质量。如果没有单元测试，就如同黑夜里没有秉烛的行走。
对于性能，在编码过程中一定存在部分感性认知，与实际情况有部分偏差，而性能测试则能很好地斧正这种差异。
11、产品化
目前，在国内大多数人都将Node以实验性质的方式来使用，国外已经有知名的项目将Node应用在实际的生产环境中，如eBay的数据中间层、Linkedin移动应用的服务器端等。本章将详细介绍将Node产品化过程中需要注重的一些细节，这些细节其实是具备普适性的，并非Node所独有。鉴于部分Node开发者可能从前端转来，为了完善Node生态的介绍，所以添加了此章。尽管因为熟悉JavaScript，可以较好地上手Node，但是事实上从演示原型到产品还有较长的缝隙需要去填补。
在实际的产品中，需要很多非编码相关的工作以保证项目的进展和产品的正常运行等，这些细节包括工程化、架构、容灾备份、部署和运维等。只有这些任务在持续性进行，才表明项目是活着的。
11.1 项目工程化
所谓的工程化，可以理解为项目的组织能力。体现在文件上，就是文件的组织能力。对于不同类型的项目，其组织方式也有所不同。除此之外，还应当有能够将整个项目串联起来的灵魂性文件。
项目的组织就犹如行军作战的阵法和章法，混乱而无目的的军队几乎不可能打胜仗,有其形有其魂的组织的生命周期才会更长，其形态才更稳固。
在项目工程化过程中，最基本的几步是目录结构、构建工具、编码规范和代码审查等。
11.2 部署流程
11.3 性能
11.4 日志
11.5 监控报警
11.6 稳定性
11.7 异构共存
11.8 总结
一般而言，决定用一项技术进行产品开发时，只有最早期是与这门技术完全相关的。随着时间的迁移，要解决的已经不是原来的问题了，一门技术只能在一定层面上发挥出它的优势来。用Node也是一样，随着开发的进展、涉及层面的增多，我们看到在产品的角度要解决的问题依然是大部分技术都要解决的问题。我们希望读者能够将Node纳人到新的层面上进行考虑，使它更适应产品，在产品中发挥出更大的优势来。
下一章介绍：搭建局域NPM仓库