测试驱动开发 TDD

概述：

Kent Beck 先生最早在其极限编程（英语：Extreme programming，缩写为XP）方法论中，向大家推荐“测试驱动”这一最佳实践，还专门撰写了《测试驱动开发》一书，详细说明如何实现。经过几年的迅猛发展，测试驱动开发已经成长为一门独立的软件开发技术，其名气甚至盖过了极限编程。

简介：

测试驱动开发（Test Driven Development,缩写TDD）是极限编程的一个重要组成部分，它的基本思想就是在开发功能代码之前，先编写测试代码。

也就是说在明确要开发某个功能后，首先思考如何对这个功能进行测试，并完成测试代码的编写，然后编写相关的代码满足这些测试用例。然后循环进行添加其他功能，直到完成全部功能的开发。

优点:

1. 完工时完工。表明开发人员可以很清楚的看到自己的这段工作已经结束了，而传统的方式很难知道什么时候编码工作结束了。
2. 全面正确的认识代码和利用代码，而传统的方式没有这个机会。
3. 开发小组间降低了交流成本，提高了相互信赖程度。
4. 避免了过渡设计。
5. 系统可以与详尽的测试集一起发布，从而对程序的将来版本的修改和扩展提供方便。
6. 大部分时间代码处在高质量状态，100％的时间里成果是可见的。
7. 为减少文档和代码之间存在的细微的差别和由这种差别所引入的Bug。
8. 在预先设计和紧急设计之间建立一种平衡点，区分哪些设计该事先做、哪些设计该迭代时做提供了一个可靠的判断依据。
9. 发现比传统测试方式更多的Bug

开发过程:

1. 明确当前要完成的功能。可以记录成一个 TODO 列表。
2. 快速完成针对此功能的测试用例编写。
3. 测试代码编译不通过。
4. 编写对应的功能代码。
5. 测试通过。
6. 对代码进行重构，并保证测试通过。
7. 循环完成所有功能的开发。

更概括的来说，可以分为三部曲:

1. 红条模式----->绿条模式----->重构

实例演示 （语法）

            describe("[Angular-Scope]", function() {

                    describe("digest", function(){
                            var scope;

                            beforeEach(function(){
                                scope = new Scope();
                            });

                            it("calls the listener function of a watch on first $digest", function() {

                                    var watchFn    = function() { return 'wat'; };
                                    var listenerFn = jasmine.createSpy();
                                    scope.$watch(watchFn, listenerFn);

                                    scope.$digest();

                                    expect(listenerFn).toHaveBeenCalled();
                            });
                    });

            });
        

1. jquery: jquery/test
2. angular.js: angular.js/test
3. ember.js: ember.js/tests

1. avalon: avalon.test
2. kissy: ?

1. 某些TestCase并不一定那么好写，你可能80%的时间花在某个TestCase的编写和设计上，然而，需求一变，你又得重写TestCase，有时候，你会发现写Test Case其实和做实际设计没有差别，你同样要考虑你TestCase的正确性，扩展性，易读性，易维护性，甚至重用性。如果说我们开发的TestCase是用来保证我们代码实现的正确性，那么，谁又来保证我们的TestCase的正确性呢？编写TestCase也需要结对或是Code review吗？软件开发有点像长跑，如果把能量花在了前半程，后半程再发力就很难了。

1. 测试驱动开发不能节省开发投入，也很少能够节省开发周期。测试开发所编写的大量测试代码都是要投入时间与精力的，我现在的代码统计显示，测试代码与实现代码的比例基本在3:2，即使因为测试驱动开发能得到一个简洁的设计，也不能弥补测试代码的工作量。当然，测试代码可以一定程度保证高质量的实现代码，从而减少后期软件测试与修正缺陷的工作周期，并进一步在软件发布后减少代码修正维护的工作量。但至少在开发阶段，两相抵消，开发周期并不能有明显改善，如果是第一次采纳测试驱动开发，甚至会延长开发周期。

1. 测试驱动开发不可能让人立即具有设计出优美解决方案的能力，或者说是优秀的分析与解决问题的能力。TDD不是Test Driven Design。它只是一个过程，也许可以帮助你发现并帮助你实现优美的解决方案，但是它不能变魔术一样，只要学会了就变出一个优美的设计出来，优秀的分析 问题与解决问题的能力还是要靠不断地学习与借鉴他人成就才能得到提高。