测试驱动javascript开发 -- 1.单元测试

　　从今天开始，我将以读书笔记的方式向大家介绍《Test-Driven JavaScript Development》相关内容。我不太清楚这本书是否已经有了中文的译本，有兴趣的朋友可以去搜索下，或者直接读英文原版。因为是读书笔记，算是供大家参考学习的资料，所以文章中很多知识或者概念的定义或者讲解可能不会那么精确。只要大家能明白我表达的内容即可，没必要太较真。

　　之前我写了《QUnit系列》有兴趣的朋友可以去阅读，他是当前比较流行的javascript测试的框架。通过学习QUnit相关知识，觉得很有必要丰富下自己的理论知识。只有有了强大的理论基础，你在工作上才会更有指导性和针对性。

　　本文将介绍单元测试的相关知识，单元测试的好处和他面临的困难。

 

　　什么是单元测试

　　简单而言，单元测试是用来测试生产代码的一段代码，他通过在已知状态下设置一个或多个对象，执行测试代码，检查输出结果与期望值是否一致。他应该具有下面一些特点：容易开发、快速运行、在隔离的环境中测试软件组件（每个测试之间不能相互影响，保持原子性）、可重复执行等。开发单元测试的过程中，我们可能还需要使用 mock 或者 stub 方式去模拟依赖操作。

　　单元测试应该在下面的情况下运行：

• 代码开发完成之后，验证相关功能的正确性；

• 代码发生改变的时候，验证它的行为没有发生改变；

• 当系统添加了新的单元项时， 确保他的功能正确，并保证没有对系统造成影响。

 

　　在实际的工作中，大家可以使用市面上已有的测试框架进行开发，没有必要自动再动手制作自己的框架。这样做，一则可以减少开发时间、提高开发速度，再则别人框架已经提供了完善的相关api、框架也比较稳定，你不能保证你的框架就一定比别人的好。可选择的框架比较多，例如：QUnit，JSUnit等，大家可以自行找资料学习。如果学习QUnit，可以参照我之前的博文《QUnit系列》，或者去官网学习。

 

　　单元测试的好处

　　测试是一份投资，然而有些人反对单元测试，觉得他是在浪费时间。写单元测试确实需要时间，但是如果不使用它，有更好的办法吗。我们能做的恐怕只有执行一遍遍效率低下的手工测试了，而且还不一定能保证对系统的完全测试，要么就是直到问题产生的时候再测试。显而易见，单元测试还是有它的价值的，写一次测试代码，运行多次，当然有时候也需要对测试代码本身加以维护。

　　1.回归测试

　　在开发的过程中我们难免会犯错误产生一些bug，这些bug直到生产环境才发现。有时候我们修复了这个bug，但是产品发布的过程中也许会犯别的错误，导致这个bug没有修复或者再次出现。回归测试可以帮助我们解决这个问题。在产品发布之前，优先运行它，能够帮助我们即时捕获问题，得以确保产品质量。而且随着系统的变化，系统会变的越来越大，业务也许会变的越来越复杂。传统的人工回归测试可能难以应对（并不是说人工测试变的不重要），自动化测试会变得越发重要。

　　关于这点我深有体会，因为之前的公司对产品质量相当看重，系统建立了一整套机制帮助开发和维护人员及时发现系统存在的问题。这套机制包括：记录系统错误日志、自动化测试、集[代码嵌入-单元测试-demo服务器发布]于一体的build系统、还有就是传统的人工测试。在产品发布之前会先运行自动化测试，确保demo环境中的系统核心功能没有受影响。自动化测试通过之后才能进行产品发布。产品发布之后，会再次运行自动化测试，确保现网核心功能没有问题。自动化测试对保证产品质量起到了相当重要的作用。

　　当然，自动化测试有它的优势也有不足，所以还需要进行人工测试，共同保证产品的质量。

　　2.重构

　　重构就是在不影响代码功能的前提下，对他进行修改。例如：从一个方法中抽取一个帮助方法，保证代码的重用性，这就是重构；再或者对象或者方法的名字进行了修改，这也是重构。重构对于不断演进的系统，保持其架构设计的健壮性、重用性、灵活性有着相当重要的作用。当然，你需要在重构之后运行单元测试，这样才能保证你的重构对系统没有产生不良的影响。

　　3.跨浏览器测试

　　对于web开发者来说，我们开发的代码是要在不同的平台、不同的客户端上运行的。使用单元测试可以有效的减小我们测试的工作量。正所谓写一次测试代码，运行多次，我们可以在不同平台的不同客户端上运行我们的测试代码，保证我们的产品在不同环境下正常工作。

　　4.其他好处

　　精心编写的测试，对于系统来说相当于一份很好的说明文档，他可以帮助新来的开发人员更快的了解系统和相应功能。此外，通过编写测试，也可以帮助开发人员理清代码开发的思路。

 

　　单元测试面临的困难

　　些单元测试其实不是件容易的事，写出良好的单元测试需要不断的实践，是件具有挑战的事情。上节中提到的单元测试的好处，是建立在遵循最佳实践的基础上获得的。如果你写的是糟糕的单元测试，情况则完全不同，你会发现这种测试完全是在浪费时间，而且增加了维护成本。

　　为了写出好的单元测试，你必须保证你的代码是可测试的。当你为一个可测试性不好的系统引入测试的时候，你会发现你的工作完全是一项不可完成的挑战。反过来也说明，单元测试对于暴露紧密耦合的代码和分离关注点是有帮助的。

　　本书会通过一些具体的实例，来向大家介绍如何编写可测试的代码，以及如何写出好的单元测试。

 

　　学学单元测试真的挺好，除了可以用来提高产品质量外，对于提高自己代码书写质量还是有帮助的，可以让自己养成很好的代码编写习惯。