|
|
有一本书就叫<<测试驱动开发>> , 我没有看过,这里仅谈论我所理解的"测试驱动开发".
我对这句话的理解是:
1) 任何一次提交新的代码都需要添加针对这些新功能的测试用例
2) 无论设计函数还是类, 对外暴露的接口都应该做到明确, 清晰, 不会给人模棱两可的感觉,提供的功能点尽可能的单一, do one thing, do it well.
简而言之, 我所理解的"测试驱动开发", 十分强调对接口的设计, 以及针对这个接口所需要考虑的异常和测试用例.接口是对外的保证, 而测试用例是验收者, 每次的修改, 都需要保证之前和现在的用例能顺利通过.
所以, 对开发人员来说, 如果有这个"测试驱动开发"的观念, 那么在设计编写代码的时候会很容易的形成几个好习惯, 比如他会反问自己以下几个问题:
1) 新增的代码提供的是什么功能? 功能点是否足够的单一, 明确, 比如本次测试的代码仅针对功能A, 下一次的仅针对功能B, 假如B功能还依赖于A功能, 那么首先要保证A功能点正确提交.切忌万不得已的情况下不可以将多个功能点放在一次提交中, 这样, 以后回溯问题时会加大难度, 也会给codereview等带来困难.
2) 新增的功能, 对外暴露的接口是哪些?有没有冗余, 不明确的接口设计?这些接口是不是刚刚好不多不少足够了?
3) 对新增的功能, 明确了对外应该提供什么接口之后, 还需要反问自己:可能在哪些情况下出错, 每种出错的情况应该如何处理, 如何通知调用者, 代码的注释是不是对一些情况作了说明.
4) 最后, 对新增的功能, 考虑了哪些测试用例, 测试是否充分, 是否考虑了很多异常的情况?
所以, 每次的代码提交都是一件很严肃的事情, 这意味着, 你对系统现有的代码做出了一些修改, 可能是接口的修改, 可能是实现的修改.如何能保证你的修改没有问题, codereview是一点, 好的codereview是一件很耗时的事情, 这需要reviewer负责任,同时最好还要多少对这部分代码有了解.如果reviewer能力较强, 又比较负责, 那么一次review相当于是一个老师在阅读作业, 他会给出你一些建议;反之, 如果你作为reviewer去review一个高水平的人的代码, 又可以从阅读中学习对方的思路.总而言之, 我觉得做好codereview是一件能够迅速提高"经验值"的捷径, 早前我阅读过许多开源项目, 学习了很多别人的技巧思路, codereview比之更近了一步--因为我还有机会与作者面对面的一起交流.另外, 除了codereview之外, 每次提交都有测试用例, 也是保证代码质量的方式之一, 如果把代码比做一个球场, 那么测试用例就是站在这个球场门口进行安检工作的保安, 不论做了什么修改, 只要保证测试用例写的好, 那么基本上都跑不过这个保安的掌心.有了测试用例, 项目的修改才有了保证, 它所提供的功能, 都是可控的,有保证的.
另外, 每次提交的修改功能点尽量的单一也是很重要的一点, 因为假设你想做的事情很多, 比如做了A又想做B,发现做B功能需要实现C功能,实现C功能首先要做D功能....子子孙孙,无穷尽也.这样会导致你的代码提交codereview时被通过的时间慢(原因有很多, 比如你需要提交测试用例多了, 比如别人的codereview时间多了).还有一点, 假如别人赶在你之前提交了代码, 而你的修改需要依赖别人的代码, 这样导致了你需要合并别人的改动, 这又是一件很麻烦的事情.
所以, 当接手一个任务时, 如何按照层次顺序划分任务, 每次提交都保证尽可能提交少的功能点, 而且又能保证每次的提交都有严格的测试用例, 也是对开发人员的一个考验.当然,这些也许在动手的时候不能百分百的考虑清楚, 但是如果完全的没有考虑过, 上手就做, 迟早都要还的.
另外, 有了同新增代码一起提交测试用例的要求之后, "看上去"每次提交的速度慢了, 因为还需要撰写测试用例, 所以对任务时间点的估计可能也需要改变, 我个人的估计是写代码时间 : 测试时间(包括写测试用例+改bug) : 根据codereview修改代码的三者之间比例大概为4:3:3, 所以如果一个任务给我五个工作日的时间完成, 也许以前我到了第四天才编码完成, 而现在就要尽量做到第三天之内能完成编码了.不过这个比例并不确定, 依个人的素质而定, 有的人写代码质量很高, 自己已经把很多情况在写的时候考虑进去了, 所以后期测试和codereview时出现问题的机会少, 反之, 有的人的代码质量较差的, 可能经常在codereview的时候被打回去重构(甚至于重写)的, 后面的比例就要增加了.以我而言, 如果能在保证代码质量的同时, 减少后面两项的时间比例, 那应该是说明了我的代码质量有了提高了.
总而言之, 接口的设计, 任务层次顺序的划分, 都是很考验人经验的活, 语言的表达总是苍白的, 需要实实在在的去实践体会.
K.I.S.S
|