成熟
经过了一段时间的迷茫和设计的不断返工，计划的不断延误。终于开始认清了真相，也真的理解了一句话，"质量是设计出来!"，同时明白了"抽象"的必要性，并且还是会使用MOCK了!
哎~，这些收获付出了很多的代价呀!项目的合伙人因为计划不断厌恶，想杀我心都有，每次去用户那里，用户总语气很怪强调"专家"这两个字(我朋友为了接项目，忽悠客户说我是很牛的专家...)，我顶着这些压力，还在不停的重构，不停的写着测试代码。
不过，单元测试的过程并没有很大的改善，主要还是一个复杂的方法里面的业务规则很多，而且代码也多，方法内部依赖的环境因素和依赖对象也很多，当出现这种情况的时候，去写它的测试代码简直是一个十分痛苦的事情，而且这种应付不了以后的变化。这种代码代码本来就多，当需要变化的时候，看代码就需要N久时间，更别说还有心情在去理会测试代码了!我对于这种问题并没有太多的解决办法，只是用时间去填补。
其实经过了这些，我知道自己欠缺什么?!那就是设计，由于设计的不够抽象，对于复杂事物分解的不够简单...，接着跑出去书城，拿着刚发的工资买了N多的关于设计的书籍。把它们抱回家，当看着这些书的时候，看着正在进行的项目，和那一大堆比代码还复杂的测试代码，觉得值了!
飞跃
"单一职责"
"依赖倒置"
"开放封闭"
"Liskov替换原则"
"迪米特法则"
这些设计的基本原则，大家是否是已经看过了太多次了，但是这些你真的每个都理解了吗?23种设计模式，每种模式都会了吗!会使用吗!你做设计的时候，是否会去思考我应该用何种模式呢?!......
这是我花了N久时间才慢慢理解和学会的东西。时间大概过了半年多，我的小项目已经开始运行，看着它正常的运行和VS2005上测试项目中的一排"测试通过"的标志，无限的喜悦。我学会了设计，理解了测试驱动开发，并且写测试代码不在烦恼，而是如此的简单，"设计完后就马上去构思测试代码，如果觉得测试代码复杂，又回来修改设计，直到交互都简单为止"，这成为我现在的一种习惯。学会这些的同时我又拿到了项目Money，真是爽呀!
经历过这些，我的领会是：在做单元测试之前，你必须要学会设计。设计原则和设计模式是你需要要去掌握和理解的，要让自己在做设计的时候，不会去想"我是否应该用哪种模式"，而已灵活运用，根据具体的情况去做，因为你要做到"无剑胜有胜"!
只有简单的东西才容易写，容易测试。代码变的简单，单元测试同样会变的简单。所以其中最关键的就是你如何将复杂的东西简化。虽然谁都知道这个道理，但是要真正做到还是很不容易的。需要理解，需要实践，需要时间去积累...
这是我做单元测试，并学会测试驱动开发的一个过程，现在虽然自己还是一只"小鸟"，但是我可以让代码看上去简单，有了一大堆测试代码的保证，降低了变更的风险。
工作还在继续，还向着新的目标前进......
文章来源于领测软件测试网 https://www.ltesting.net/