Monthly Archives: September 2009

尝试了一下把TDD用到真正的项目中

这次的TDD不是那么严格,我并没有先写测试用例再写代码,而只是把单元模块写好之后立即写单元测试,同时注意维护一套Test Suite,确保单元测试的覆盖程度,并作为代码重构后的验收标准。

总体上,搞了一段时间之后,我觉得代码质量比较高(Bug率较低),但效率很难让人满意,并且我也并不那么快乐。

   1.写单元测试几乎成了一种负担。

        a. 手动生成测试类太辛苦太无聊。不过后来发现了Fast Code Plugin,情况有所改观

        b. 写一个代码立即写一个测试类,不符合批量作业的原理:你的头脑要不停地从开发者到测试者两者之间切换,效率低下,而且很让人沮丧;当重构发生时,单元测试也要重构,这更加让人不胜奇烦。后来我想的办法是先把一定的代码全部写好之后写测试来测,为了不遗漏,我会在写代码时做个标记(比如throw UnsupportedOperationException),然后在测试时按这些标记找到应测类。

        c.单元测试不是那么好写。我的经验发现单元测试的代码量往往会超过被测代码。比如说,EasyMock的三步曲还是不够简洁,用JAVA写测试数据也挺麻烦。最终我发现,单元测试使开发周期加倍。

  

   2.TDD提倡的自底向上的设计思路也会搞得很低效。 自底向上的设计,即先写代码再重构,的确可以让你的脑子免于很多思考,先把车开到山前,到了山前再开路。但我的体会就是“山前开路”发生的太频繁了,而且“返工”太多了。9点开好的一条临时小径,11点就得被重构掉,加上它的测试用例,再考虑到CVS等因素,反复重构非常低效。 所以我后来觉得,还是先设计为好。

不过,虽然有上面那些问题,但我觉得TDD仍是一条应该坚持走下去的路。虽然首次开发时时间较短,但由于Test Suite的存在,日后的维护代价会轻很多。