这次的TDD不是那么严格，我并没有先写测试用例再写代码，而只是把单元模块写好之后立即写单元测试，同时注意维护一套Test Suite，确保单元测试的覆盖程度，并作为代码重构后的验收标准。
总体上，搞了一段时间之后，我觉得代码质量比较高（Bug率较低），但效率很难让人满意，并且我也并不那么快乐。
1.写单元测试几乎成了一种负担。
a. 手动生成测试类太辛苦太无聊。不过后来发现了Fast Code Plugin，情况有所改观
b. 写一个代码立即写一个测试类，不符合批量作业的原理：你的头脑要不停地从开发者到测试者两者之间切换，效率低下，而且很让人沮丧；当重构发生时，单元测试也要重构，这更加让人不胜奇烦。后来我想的办法是先把一定的代码全部写好之后写测试来测，为了不遗漏，我会在写代码时做个标记(比如throw UnsupportedOperationException)，然后在测试时按这些标记找到应测类。
c.单元测试不是那么好写。我的经验发现单元测试的代码量往往会超过被测代码。比如说，EasyMock的三步曲还是不够简洁，用JAVA写测试数据也挺麻烦。最终我发现，单元测试使开发周期加倍。
2.TDD提倡的自底向上的设计思路也会搞得很低效。 自底向上的设计，即先写代码再重构，的确可以让你的脑子免于很多思考，先把车开到山前，到了山前再开路。但我的体会就是“山前开路”发生的太频繁了，而且“返工”太多了。9点开好的一条临时小径，11点就得被重构掉，加上它的测试用例，再考虑到CVS等因素，反复重构非常低效。 所以我后来觉得，还是先设计为好。
不过，虽然有上面那些问题，但我觉得TDD仍是一条应该坚持走下去的路。虽然首次开发时时间较短，但由于Test Suite的存在，日后的维护代价会轻很多。