[意义]架构之路（四）：测试驱动

架构之路（四）：测试驱动-CSDN.NET
http://www.csdn.net/article/2015-09-30/2825831
需求文档可测试化

我第一点想到的，就是需求文档应该可测试化。我不太明白，这样简单有效的一个工作，为什么几乎没有人去做？因为发包方的原因？

大家接触到的需求文档是什么样子的？我从来没有看到过一份我满意的需求文档。都是word格式的，文字加上图片说明。文字都是简单的陈述句说明，比如：用户名不能重复。简明扼要，是不是？是你妈个逼！sorry，我爆粗口了，但这种文档真的会让你疯掉的！

你觉得这是一个很简单的需求，是吧？然后你就噼里啪啦的开始编码了，20分钟搞定，踌躇满志，小case啊！

然后噩梦就开始了。

第一次验收。发包方的眉毛皱了起来，“嗯，其实我想的是那种：当用户把用户名输入完成之后，能立即显示该用户名是否重复，而不用点击提交之后才显示这个结果，你看XXXX网站就是这样的”。OK，Ajax效果是吧？好呢，我改。感谢asp.net mvc，有现成的Remote实现，20分钟，收工，over！

第二次验收。发包方有点不耐烦了，“你这个还是不对啊！你看我给你说了XXXX网站，如果这个用户名不重复的话，要打个勾啊；错了，打个叉，再显示‘用户名重复’的提示啊……”。你有没有想哭的感觉？我忍，含着泪，找个勾勾叉叉的图片，再改。

第三次验收。发包方终于笑了，“不错不错！”你心里一块石头落了地。但这发包方思维很严密，他突然想到一个问题，“你说，假如两个用户同时注册，用的是同样的用户名，这个用户名也是以前数据库里没有的。所以页面输入的时候，肯定是显示用户名有效，是吧？所以他们都可以提交，但他们用户名又是一样的，都提交了就重复了，这时候会发生什么情况？……”你仔细的想了想，是不是觉得晴天霹雳天旋地转？

这只是一个非常非常简单普通的需求，都可以演化出无数种具体实现，更何况其他你可能从来没接触过的复杂需求？你作为一个程序员，只是觉得苦逼郁闷或者还得赶工加班；但对于公司来说，这就是个大麻烦了：工期延误、费用增加、信誉破产……这时候该追究谁的责任？我们可以设想这样的对话：