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