测试驱动开发总结

   1、何为测试驱动开发
   
    简而言之，测试驱动开发是：
   
    先定义代码的行为，再定义行为的实现
   
    2、为什么要进行测试驱动开发
   
    2.1 需求与设计驱动
   
    代码应该具有什么样的行为由什么决定：
   
    由客户的需求决定（这里的客户可以是使用产品的终客户，更多的情况下是其他的程序员）
   
    用什么反映需求，用什么来验证需求是否被充分满足：
   
    测试用例
   
    先写测试用例说白了是先用可验证的方式表达出客户的需求，表达出“通过这样的验证，代码的实现是能充分满足客户需求的”，从而提升开发者的勇气，让开发者明确目标，而且目标是可以达到的，因为目标已经通过测试用例表达出来了，是一个完全看得见摸得着的东西。
   
    需求可不可能有问题？
   
    当然可能有问题，如果你发现在编码之前测试用例无法写，而你所考虑到的一切设计手段都用过了，也许问题出在需求那里，比如一个实现起来很困难的需求其实是可以通过另一个容易实现的需求来满足的，因此这个需求也许并不必要。测试驱动方法是一个在早期发现需求缺陷的手段。
   
    设计可不可能有问题？
   
    更可能有问题，测试用例无法写， 但需求是合理而且必须的情况下，也许需要检验一下你的设计是否合理，是否需要考虑用更简单的设计、更加松耦合紧内聚的设计来达到需求目标。一个紧耦合松内聚的设计，要对之进行测试无疑是很困难的。测试驱动方法是一个在早期发现设计缺陷的手段，是让开发者在编码前仔细推敲自己的设计是否足够、是否合理，从而减少编码已经大半才发现重大设计缺陷的几率。
   
    测试用例是什么：
   
    代码将长成的样子，通过这些用例，我们通过客户的视角来审视设计、实现是否合理。
   
    需求决定一切，
   
    在需求都没有考虑清楚的情况下开始编码是不明智的。
   
    2.2 后期限（DeadLine）终结者
   
    因为已经到了后期限，所以没空作开发者测试了吗？
   
    测试驱动开发的实践结果是：
   
    测试驱动加快了软件开发的速度，因为它大大缩减了调试的时间
   
    主要的开发时间不是耗费在编码上，而是debug。如果你经常运行测试，bug可以更早的显露出来。如果只是距离你后一次写测试代码不久，你能知道是代码的哪一部分有问题。
   
    2.3 重构的安全保证
   
    重构是一项日常工作，而不是阶段性工作，不要等东西坏到无法再修只能丢掉，而是一旦发现损坏马上维修。 如何保证重构不引入新的问题：
   
    一个完备的、可自动化运行的用例库无疑是重构好的安全保证。
   
    2.4 明确编码的目标
   
    关键在于 “用户怎么来用这个新特性”
   
    先写测试代码的另一个好处在于测试帮助你集中在新特性的接口上而不是其实现。你会问自己“用户怎么来用这个新特性？” 让测试跑起来是给这个特性作了结论，你也清楚了自己将要作的是什么。
   
    3、如何进行测试驱动开发
   
    下面结合我在端口管理模块的开发工作中实践测试驱动开发的经验谈谈几点关于“如何进行测试驱动开发”的看法。
   
    3.1 测试驱动开发，作的是单元测试
   
    单元测试和集成测试、系统测试不同，单元测试是直接验证开发者代码实现内部逻辑性、外部需求特性是否正常的测试方法。这些是在编码之前一个开发者需要考虑的事情，也是“开发前测试”需要考虑的事情。单元测试应该脱离一个正常运作的系统、一个已经集成好了的功能子系统来进行。不要以集成测试、系统测试的角度来看待单元测试。