Test-Driven Development(测试驱动开发) tddxp单元测试

　TDD的基本思路 是通过测试来推动整个开发的进行。

　　优势：

　　1.通过编写测试用例 可以确保对需求描述的无二意（无歧义）

　　2.编写测试用例  也是一种代码设计的过程

　　3.测试用例是对代码的最好的解释

　　4.测试驱动开发提供的测试集就可以作为你编码信心的来源

　　5.测试用例可以保障代码的正确性，能够迅速发现、定位bug

　　过程：

　　测试驱动开发的基本过程如下：

　　1） 明确当前要完成的功能。可以记录成一个 TODO 列表。

　　2） 快速完成针对此功能的测试用例编写。

　　3） 测试代码编译不通过。

　　4） 编写对应的功能代码。

　　5） 测试通过。

　　6） 对代码进行重构，并保证测试通过。

　　7） 循环完成所有功能的开发。

　　TDD的原则：

　　1） 测试隔离。不同代码的测试应该相互隔离。对一块代码的测试只考虑此代码的测试，不要考虑其实现细节（比如它使用了其他类的边界条件）。

　　2） 测试列表。需要测试的功能点很多。应该在任何阶段想添加功能需求问题时，把相关功能点加到测试列表中，然后继续手头工作。

　　3） 先写断言。测试代码编写时，应该首先编写对功能代码的判断用的断言语句，然后编写相应的辅助语句。

　　4） 可测试性。功能代码设计、开发时应该具有较强的可测试性。其实遵循比较好的设计原则的代码都具备较好的测试性。

　　5） 及时重构。无论是功能代码还是测试代码，对结构不合理，重复的代码等情况，在测试通过后，及时进行重构.

　　6） 小步前进。软件开发是个复杂性非常高的工作，开发过程中要考虑很多东西，包括代码的正确性、可扩展性、性能等等，很多问题都是因为复杂性太大导致的。

　　测试技术：

　　怎么编写测试用例

　　测试用例的编写就用上了传统的测试技术。

　　* 操作过程尽量模拟正常使用的过程。

　　* 全面的测试用例应该尽量做到分支覆盖，核心代码尽量做到路径覆盖。

　　* 测试数据尽量包括：真实数据、边界数据。

　　* 测试语句和测试数据应该尽量简单，容易理解。

　　* 为了避免对其他代码过多的依赖，可以实现简单的桩函数或桩类（Mock Object）。

　　* 如果内部状态非常复杂或者应该判断流程而不是状态，可以通过记录日志字符串的方式进行验证。

    * 职责转变 - 某些开发人员认为，他的工作就是实现功能，写代码；测试只是测试人员的事情，不在他的职责范围内。这是错误的认识，完备高质量的单元测试也是开发人员的职责！

    * 思维转变 - 很多开发人员拿到需求后，喜欢立刻就埋头开始写代码实现。TDD要求测试为先，开发人员首先要思考的不再是功能如何实现，而是应该如何去进行验证，并列出需要的测试场景。这是一个大的逆向思维转变。

    * 需求分析能力 - TDD比传统的编程方法需要开发人员具备更强的需求分析能力，要求开发人员对业务有跟深入的理解。