tuti写道
这次的TDD不是那么严格，我并没有先写测试用例再写代码，而只是把单元模块写好之后立即写单元测试，同时注意维护一套Test Suite，确保单元测试的覆盖程度，并作为代码重构后的验收标准。
这不是不严格的问题，你搞的根本不是TDD，充其量维护了一套自动测试用例。
既然你搞的不是TDD，就不要说TDD如何如何。
这不是不严格的问题，你搞的根本不是TDD，充其量维护了一套自动测试用例。
既然你搞的不是TDD，就不要说TDD如何如何。
我认为TDD这种方法之所以有效，本质在于：
它使得我们在开发过程中能不断的从测试用例获得反馈 ，然后在这些反馈的基础上去调整设计，自然而然的做出简单、合理的设计； 这里的核心是快速反馈，只要我写下一段代码能尽快的被客户（单元测试）使用、运行，并得到客户的反馈（好不好用、正不正确……），我就可以以此为依据来完善设计。 至于这些测试是在代码之前先写出来的还是在之后几分钟写出来的，没有什么大不了的，根据个人喜好、感觉走就行了，比如： 如果写代码时思路很乱，那就先写个测试，从外部思考，思考这个组件从外面开起来是什么样的，想清楚了以后再去想内部实现；然后完善测试、完善实现，如此反复。 反过来，如果我一开始就对实现比较清楚，有很多想法，那就直奔主题去用代码实现这些想法，写出一个最简单的实现后，立刻写个测试来验证，如此反复。
