TDD就一定要在实现前写好所有的Test Case？

 

今天做项目，和同事讨论一个细节的实现问题。纠结了很久，才发现在不改变原来设计的前提下，根本不可能实现这个细节需求。于是乎，改设计，改实现，这直接导致一批 UT 的修改甚至荒废，几天前 TDD 的很多努力都白做了。

 

事后思考原因，当初设计的缺陷是因为我们做了一个假设，在今天实现这个细节的时候，才发现这个假设根本不成立，而根本原因是设计的时候对需求的了解不够全面。这是谁的错？是设计人员的错吗？

 

我觉得没有谁能保证在实现前能把需求想得面面俱到，或者说，能保证自己设想的需求能 100% 准确。实际上，需求绝对不是在项目开始就定好的，需求也是随着项目的进展而不断演化的。所以，上面的设计人员实际上没错，这是常态。敏捷开发提倡拥抱变化，对于变化，我们不应该认为是谁错了，而应该感到高兴，说明我们的分析和设计越来越趋近于真实情况。我们应该时刻重构，时刻保证系统的松耦合和扩展性，这样就能积极响应变化。不过针对于今天的情况，我觉得仍然有可以改进的地方，就是 Test Case 的撰写。

 

对于 Test Case ，究竟应该什么时候写？ TDD 都提倡在做设计的时候写，在代码实现之前写。这样做的好处是

1.       强迫我们在写代码前就仔细思考，并做出设计。水平高的程序员在写代码前都会先想好大概的设计，但是对于水平低的程序员往往没这个习惯。所以这是一个比较好的习惯，或者是管理手段。

2.       用 Test Case 来代替设计文档。

3.       在实现前写好 case ，会让程序员目标明确且充满动力地实现目标

4.       写好实现后，重构代码， Test Case 能够保证重构的正确性

 

但是通过这么长时间的实践，我也体会到设计的时候写 TC 也有弊端。那就是当需求调整，设计调整的时候，会导致之前写的 TC 白写，又有大量的修改和重写工作，而且这种事情经常发生。这直接导致了劳动力的浪费，也推迟了项目原型的快速实现。但是如果在需求都稳定后再写，我们又丧失了 TDD 带给我们的好处。应该怎么做呢？

 

我觉得可以尝试这样来做，简单的说，就是先写主要的TC，之后再补齐。在设计的时候，只针对每一个接口写一个 TC ，这个 TC 应该是考虑系统正常运行时的情况，而不用考虑边界条件（我觉得 TC 的繁多，其实大部分都是同一个接口的不同 case ，考虑了很多边界条件）。这样就照顾到了好处 1 、好处 2 、好处 3 。在功能都稳定后，再补齐所有的 TC ，这个时候的 TC 就应该全，考虑尽量多的情况。

 

不过这里有个问题，就是何时才是功能稳定？我的一个想法是，当实际运行效果出来，然后让 stake holders 看过满意后，才叫功能稳定。但是对于这个想法，我仍然有两点质疑：

1.       如果都要等到 stake holders 看过之后，我们才能写 TC ，这个回馈周期就会比较长。那在这个期间内我们做的重构，就没有 TC 的保障。难道要等到功能稳定， TC 都补齐之后才进行重构？这个显然不太合理。

2.       Stake holders 满意之后就能肯定功能稳定了吗？ stake holders 看到的是操作流程界面上的效果，而往往一些阶段性成果都反映在后台数据里（比如今天的问题）。这个 stake holders 是很难察觉到的。

 

还需要在实践中继续摸索。

评论

2 楼 glinenator 2011-03-19  

谢谢楼上的回答。

很同意楼上 TC只是保证“当前需求”正确实现的一种手段 这句话，但是不太同意TC在任何时候都是必要的观点。

我对于TC对自动化测试的作用是毫无怀疑的，怀疑在于何时写TC。

TDD强调在实现之前写TC，但是我认为在开发初期的时候，就把底层TC都写好，一是需求变动会比较大（或者初期设计就不完善），导致TC的大量回工，实际上前面写TC的努力就白做了；二是写TC要花大量的时间，特别是mock和stub的编写，这很明显地延迟了产品原型的交付。我们团队在开发一个功能的时候，写TC花的时间往往比写业务逻辑要多很多。而敏捷开发就是强调快速迭代，快速交付阶段性成果，快速得到反馈的。

所以我觉得TC，至少是大量的TC，在实现前都全部写好，是没有必要的。

楼上提到的BDD，我也有所了解，不过也不深，我的理解是它其实是一种function test，而非UT了。不知道事先用selenium写好case算不算BDD，这样高层的测试驱动开发，我觉得在实践中似乎不太靠谱，呵呵

1 楼 darkbaby123 2011-03-18  

其实关键还是一个度的问题，因为需求总是会变，测的越细，错的越多。维护测试的成本也越高。但这也不算是一种坏事，至少不会在你改了需求后对可能产生的bug一无所知。
我现在只是把TDD当作自动化测试的手段。其实想想，如果没有测试，可能我们需要开一个控制台或者SQL管理工具之类的，手动敲代码或者写SQL来看看数据是否正确。这种事情如果发生的很频繁，手动测试和自从测试所花的成本是等价的，甚至更多。
对于LZ最后的疑惑，其实大多数的情况下，功能永远也不可能“稳定”下来。TC只是保证“当前需求”正确实现的一种手段。这点在任何时候都是必要的，因为手动测试花费的成本更多（前提是你足够细致的手动测试）。
另一个办法就是现在某些人提倡的BDD。关注于行为而不是接口。不过我觉得从某种程度而言，它也是“不过多关注底层细节”的另一种诠释