TDD只是理想化的开发方式吗？

前段日子和Manager讨论了一下开发方式的问题。其中我们就谈到了TDD的开发方式。而Manager给出的想法就是TDD是一种较为理想化的开发方式。

 

当然我并不赞同这样给TDD下定论。的确在国内大多数以结果为目标导向的软件公司中使用TDD开发的确有的理想化。

 

TDD很大范围内被认为是以开发效率来换取代码质量的一种开发方式。这点我也没法否认。我在之前的公司里的确也是以这种方式开发的，但你说他敏捷，我觉得需要三思。因为作为测试驱动，你写测试，写代码，写测试实现，修改代码，维护测试等等步骤都是要资源成本的投入的。所以完全使用单元测试为驱动的方式的确有点理想化。

 

所以我觉得使用一种相对折中的方法来解决TDD测试成本过高的缺点。那就是Use Case驱动，也就是UDD(Usercase Driver Develop)，这个Use Case并非程序员开发的单元测试，而是测试人员最终跑的系统Case，也就是真正的客户会实际使用时的E to E流程。之所以这样想的原因是： 我觉得TDD的根本目标是为了让开发人员非常的清楚自己的开发目的，限定开发人员所需开发的系统行为！TDD就能简化这个目的到一个单元测试的维度。而我们换一下思考方式，如果开发人员能够很清楚自己要做出来是什么样子，运行时是什么流程，会有哪些特殊点。开发者能够拿到整个User Case的说明信息。而他在整个开发周期中都是以实现这个User Case为目标去开发，其实效果应该是一样的。但为了更好地实现这点，有些关键的点需要关注：

1. User Case必须被定义的全面覆盖整个需求！最好能把页面流程，操作细节结构都清晰的以图形方式画出来。这个不能只有Tester单独完成，而是应该由BA和Designer来做。他们更了解需求，更需要保证测试的正确性。
2. 开发前Developer和Tester要通过和BA讨论来熟悉真正业务User Case,并且尽可能的去质疑BA对于需求的认知。这点比单纯的看需求文档更直观。
3. 质量问题，不完全是Developer的错。如果完成后质量不够，请先查Case覆盖面，就像单元测试一样，当一开始订的期盼值与实际值就不一致时，又怎么可能的取得正确的结论？BA和Designer这两个角色花在需求上的时间平均是Tester和Developer的5倍，而真正干活的却不是这些最了解需求的人，所以。他们的User Case至关重要直接决定了质量。
   

修正：这是很早以前写的文章，现在的Scrum会是更好的开发方案。