积极面:
将单元测试优先于代码, 要先考虑对类和实现的分解和优化, 对结构和可控性会保持的更好, 每次修改后都会对整体测试, 对bug挑剔会较好
消极面:
每次对代码和类的修改和拆分, 都需要考虑测试代码是否还在同一时代. 虽然后期也许可以看到更积极, 但是两个曲线的交叉点是在什么时候呢?
我们现有的项目使用这样的思维是如何评估它的优劣呢?
关于使用:
按照基本路径原则, 当单元测试覆盖率较低的时候, 它并不是完全可信的, 但是当它覆盖率较高的时候又不容易维护.
做到if, while, for, and, or, case, 好数据, 坏数据的覆盖, 它的规模会膨胀的像个大象, 扩展和维护的工作量会次方的增加.
小心的开发先行的单元测试, 如果有搭档的话, 并且和搭档同时思考程序的结构和走向, 尽量拿出简洁的思维, 对待测试先行指望着后期的实时重构是件很大的工作量....
它的灵活性并不想想像的那么好, 带来的好处也不像想像的那么差.
2008.3.9 鸟记.