最近在看图灵的那几本重构书,被各种大师洗脑中,感觉“无测试不代码”,“TDD才是王道”。
目前手头的工作感觉非常适合用TDD,开发一个类库,与旧的代码没有关联,且非常容易放入测试容器中,开发时间也算充裕。只是由于没有相关经验,不敢乱来。挣扎了一上午,还是放弃了,边想边做,走了老路。回家路上,回想白天的编码过程,感觉传统开发模式和TDD似乎有些重合。
对比的看,因为对测试用例编写的不熟悉,传统开发会节约大量的时间,但随着测试用例编写效率的提高,我感觉传统开发模式的优势会减弱,但永远不会消失。而由于暂时不会有不能承受编译成本的项目,TDD在调试阶段的优势不是非常的突出。
总结:我个人认为如果代码不准备重构或者没时间重构,需求变动频繁的情况下,使用TDD的效果可能不会很好;反之,TDD应该更值得考虑。
(本人工作经验严重不足,希望抛砖引玉,静候大家高见)
目前手头的工作感觉非常适合用TDD,开发一个类库,与旧的代码没有关联,且非常容易放入测试容器中,开发时间也算充裕。只是由于没有相关经验,不敢乱来。挣扎了一上午,还是放弃了,边想边做,走了老路。回家路上,回想白天的编码过程,感觉传统开发模式和TDD似乎有些重合。
传统开发 |
TDD |
传统开发优势 |
TDD优势 |
构思代码 |
编写测试用例 |
节省时间 |
为思考路径留下记录,便于重构 |
编写代码 |
编写代码 |
- |
- |
调试 |
启动测试,发现问题 |
调试方式灵活 |
节约编译时间 |
修改并重复调试 |
修改并重复调试 |
- |
- |
总结:我个人认为如果代码不准备重构或者没时间重构,需求变动频繁的情况下,使用TDD的效果可能不会很好;反之,TDD应该更值得考虑。
(本人工作经验严重不足,希望抛砖引玉,静候大家高见)