|
测试驱动开发（Test-driven development，缩写为TDD），顾名思义，它是要求先写测试程序再编码实现功能的一种软件开发方法。测试驱动开发是极限编程中中的最佳实践。自20世纪90年代诞生以来，测试驱动开发越来越受到业界的追捧。 那么，测试驱动开发究竟好在哪里呢？在回答这个问题之前，我们先说说传统的先编码后测试的方法会带来哪些问题： 1. 文档与代码不同步导致理解偏差 软件开发的过程是离不开文档的。 在动手编码之前，我们需要对理解并定义好需求，形成需求文档，之后，要对软件进行设计，形成设计文档，然后才会开始编码。 实施GJB5000A的组织会要求有软件研制任务书、软件需求规格说明和软件设计说明，即使不严格执行GJB438B，对这些文档简化，那你也需要维护需求列表、用例图、类图等文档。因为没有这些文档，测试就无法进行。 即使你是一个人的项目，没有这些文档，你就无法保证你的测试没有疏漏。 既然离不开这些文档，那我们在测试发现Bug并且修复这些Bug后，同时就要修改这些文档，以使文档和代码是同步的。而这个同步的工作是靠人来做的，不仅费时费力，还不可靠。在项目进度的压力下，要做好这个同步工作谈何容易！而如果做不好文档和代码同步，这些过时的文档，就会极大地影响测试的进行。 2. 传统的测试效率低下 传统的测试虽然能够帮助我们找出代码中存在的问题，但预期的测试结果是保存在人脑中的，每次测试都要手工运行测试程序，并靠人的眼睛和大脑去判断结果是否符合人脑中的预期结果，这样不但劳神费力，而且效率低下。 3. 测试滞后耽误修复时间 传统的测试发现问题的时，这个问题在代码中存在很长时间了。我们都知道，软件缺陷发现得越早，修复缺陷的成本就越低。如果我们能够在缺陷刚刚产生就能发现并去除缺陷，会节约很多成本，提高开发效率。 4. 传统的测试发现问题后软件调试的自动化程度低，导致代码维护时间长 在传统的测试发现代码的问题后，程序员通常用设置断点的方法来调试程序。程序员通过仔细观察每个断点处理相关变量的取值变化，找出并解决问题。但这个过程很繁琐：首先需要在IDE里把程序运行起来（有些系统甚至无法在IDE里运行，而只能看log这样的日志），然后重现错误，观察错误，定位错误，猜测出错点，并相应地设置断点，再debug运行程序，观察断点处的变量值，分析并查找错误。而且这个繁琐的过程还无法自动化地反复使用。 而测试驱动开发则是戴两顶帽子思考的开发方式：先戴上实现功能的帽子，在测试的辅助下，快速实现其功能；再戴上重构的帽子，在测试的保护下，通过去除冗余的代码，提高代码质量。 测试驱动开发具有以下优势： 1. 快速反馈 测试驱动开发是用测试程序来指出代码的问题，它把代码本身当成代码编写的沟通基础，这会让程序员、测试工程师、产品专家等更快速地理解代码行为、交流代码问题。 2. 自动判错 测试驱动开发通过测试程序把测试的期望值写成断言告诉计算机，使其能够代替人脑自动判断程序的运行结果是否符合预期，这会比让程序员自己判断软件功能是否正确实现来得更加快捷。 3. 及早查错 先测试后编码的开发方式，可以确保及时发现代码中的错误；再加上频繁地运行测试，这都会让程序员、测试工程师和开发经理等人快速地处理代码问题。 4. 精益内核 测试驱动开发作为极限编程的最佳实践之一，它专注于用“最少量”的代码让编译和测试快速通过，再用重构来治理代码的坏味道。测试驱动开发通过计算机自动且反复运行的精简的测试，把Bug限定在一个个粒度很小的测试之内，这会使得程序员可以更快地进行代码维护。 总之，测试驱动开发可以完美地解决传统测试后行带来的问题，降低开发成本，提高开发质量和效率。 这正是： 传统测试问题多，效率低下成本高 测试驱动开发好，省时省力质量高 参考书目：驯服烂代码：在编程操练中悟道，作者：伍斌，出版社：机械工业出版社 |
|
|
