对测试驱动开发的感悟[2]

　　对测试驱动开发的感悟[2]   软件测试工具

　　成熟

　　经过了一段时间的迷茫和设计的不断返工，计划的不断延误。终于开始认清了真相，也真的理解了一句话，"质量是设计出来!"，同时明白了"抽象"的必要性，并且还是会使用MOCK了!

　　哎~，这些收获付出了很多的代价呀!项目的合伙人因为计划不断厌恶，想杀我心都有，每次去用户那里，用户总语气很怪强调"专家"这两个字(我朋友为了接项目，忽悠客户说我是很牛的专家...)，我顶着这些压力，还在不停的重构，不停的写着测试代码。

　　不过，单元测试的过程并没有很大的改善，主要还是一个复杂的方法里面的业务规则很多，而且代码也多，方法内部依赖的环境因素和依赖对象也很多，当出现这种情况的时候，去写它的测试代码简直是一个十分痛苦的事情，而且这种应付不了以后的变化。这种代码代码本来就多，当需要变化的时候，看代码就需要N久时间，更别说还有心情在去理会测试代码了!我对于这种问题并没有太多的解决办法，只是用时间去填补。

　　其实经过了这些，我知道自己欠缺什么?!那就是设计，由于设计的不够抽象，对于复杂事物分解的不够简单...，接着跑出去书城，拿着刚发的工资买了N多的关于设计的书籍。把它们抱回家，当看着这些书的时候，看着正在进行的项目，和那一大堆比代码还复杂的测试代码，觉得值了!

　　飞跃

　　"单一职责"

　　"依赖倒置"

　　"开放封闭"

　　"Liskov替换原则"

　　"迪米特法则"

　　这些设计的基本原则，大家是否是已经看过了太多次了，但是这些你真的每个都理解了吗?23种设计模式，每种模式都会了吗!会使用吗!你做设计的时候，是否会去思考我应该用何种模式呢?!......

　　这是我花了N久时间才慢慢理解和学会的东西。时间大概过了半年多，我的小项目已经开始运行，看着它正常的运行和VS2005上测试项目中的一排"测试通过"的标志，无限的喜悦。我学会了设计，理解了测试驱动开发，并且写测试代码不在烦恼，而是如此的简单，"设计完后就马上去构思测试代码，如果觉得测试代码复杂，又回来修改设计，直到交互都简单为止"，这成为我现在的一种习惯。学会这些的同时我又拿到了项目Money，真是爽呀!

　　经历过这些，我的领会是：在做单元测试之前，你必须要学会设计。设计原则和设计模式是你需要要去掌握和理解的，要让自己在做设计的时候，不会去想"我是否应该用哪种模式"，而已灵活运用，根据具体的情况去做，因为你要做到"无剑胜有胜"!

　　只有简单的东西才容易写，容易测试。代码变的简单，单元测试同样会变的简单。所以其中最关键的就是你如何将复杂的东西简化。虽然谁都知道这个道理，但是要真正做到还是很不容易的。需要理解，需要实践，需要时间去积累...

　　这是我做单元测试，并学会测试驱动开发的一个过程，现在虽然自己还是一只"小鸟"，但是我可以让代码看上去简单，有了一大堆测试代码的保证，降低了变更的风险。

　　工作还在继续，还向着新的目标前进......

原文转自：http://www.ltesting.net