然而，TDD并不妨碍你深入思考，只是劝你在实现时步子不要太大，小步前进 获得对问题的进一步认识以随时调整设计和实现。不过今天不争论TDD的哲学问 题，我们只是关注用什么样的实践来消除对于TDD测试完备性的疑虑。

事实上，完全可以根据需求文档，验收条件，进行"深入思考"，从一开始就 写下所有能想到的单元测试用例，就跟测试人员在产品出来前就对着需求准备测 试用例一样。

哦，等等，这还叫 TDD 吗? TDD 所强调的小步前进，随时应变哪里去了？为 全面的测试用例所花费的大量努力岂不是有浪费的风险?

嗯，不错，TDD强调小步前进的原因就是要避免浪费。如果我们能找到一种方 法，既能够提醒我们不要忘记需求，又让我们在需求变化时不致浪费太多，岂不 是皆大欢喜?

想想，我们用什么来描述需求?是测试用例名称，而不是测试用例的函数体， 而名称的书写几乎是没有成本的。从需求文档中把验收条件抠出来即可。如：

public void test_会被认为不服从调配_if_the_seaman_在当前职位 上曾经旷工() { 　　　　 // TODO 　　 } 　　 public void test_会被认为不服从调配_if_the_seaman_在当前职位上 曾经请过病假() { 　　　　 // TODO 　　 } 　　 public void test_会被认为不服从调配_if_the_seaman_在当前职位上 曾经请过事假() { 　　　　 // TODO 　　 } 　　 public void test_会被认为不服从调配_if_the_seaman_在当前职位上 曾经被遣返() { 　　　　 // TODO 　　 } 　　 public void test_不会被认为不服从调配_if_the_seaman_在当前职位 上从未旷工_请病假_请事假_和遣返() { 　　　　 // TODO 　　 }

两分钟，我们就把这个用户故事的测试用例按照验收条件里说的全部描述出 来了。函数体全部都是空的，因此所有的测试都是通过的，不会强迫你一次性把 所有的测试都实现。

每次你流览或修改这段代码，空的函数体或里面的// TODO都会提醒你还有测 试没有完成。即使你不在这个特性上工作了，切换过来的Pair也会从你遗留的测 试用例名称中迅速的了解需要做什么。

这种方法是怎么解决问题的呢?

第一，还是让我们正视现实：如果需求描述不和代码放在一起，开发人员很 少会在开发过程中去翻阅需求文档，甚至是特性编码结束后。这在成熟的开发团 队中会有改善，但仍然不可避免。把需求描述以测试用例名称的方式放进代码， 便会无时无刻不在提醒开发者，还有这个这个这个验收条件没满足。

第二，我们依然坚持了以下原则：

用测试用例的名字来描述需求。

小步前进，编写一个测试用例，实现一段产品代码，编写下一个测试用例， 实现下一段产品代码。（因为所有的未完成测试都是通过的，不妨碍你运行测试 ，提交代码和持续集成）

当实现过程中发现事情并不是当初想的那样时，随时更改或删除之前写的测 试用例，不会造成大的浪费。（因为只是函数名加空的函数体，成本很低）

在开始写下"所有"的测试用例名称并不意味着一劳永逸。中间当需求发生变 化，我们需要对应的添加或删除一部分测试用例。在实现的过程中，发现某些条 件不在验收范围内，或许是之前没考虑到，那么跟BA/QA确认后，需要添加到用 例列表中。

(细心的读者可能发现，这里面存在着重复。就是以普通文本形式存在的验收 条件和以测试用例名称存在的验收条件。或许应该有类似SVN2Wiki的工具，来消 除这类重复)

当然，完备性还有其它的含义和检测条件，不是说你提前多写几个用例就是 完备了。这里只是用一种成本最低的方式来解决问题。

TDD实践之实用主义(3)

3. 一个环境，多个断言

随着时间的推移，项目组发现测试运行的越来越慢。当然

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!