TDD：在哪里开始第一次测试

所以我做了一些单元测试,并且有经验的写测试,但我还没有完全接受TDD作为设计工具.

我目前的项目是重新组建一个生成序列号的现有系统,作为公司组装过程的一部分.由于查看现有系统,我对当前的流程和工作流程有一个了解.我还有一个新的要求清单,以及如何修改工作流程.

我觉得我准备好开始编写程序了,我决定强迫自己从头到尾都是做TDD.

但现在我不知道从哪里开始. (我也想知道我是否欺骗TDD进程已经有了用户的程序流的想法.)

用户流是真正的串行,只是一系列的步骤.例如,第一步是：

>用户提交制造订单编号,并收到该订单材料清单的可序列化部件号

当用户选择其中一个部件号时,下一步将开始.

所以我以为可以把这个第一步作为起点.我知道我想要一块代码,它需要一个制造订单编号,并返回零件编号列表.

// This isn't what I'd want my code to end up looking like
// but it is the simplest statement of what I want
IList<string> partNumbers = GetPartNumbersForMfgOrder(string mfgOrder);

阅读肯特·贝克的例子,他谈到选择小测试.这似乎是一个很大的黑盒子.它需要一个制造订单存储库,我必须爬行一个产品结构树,找到这个mfg订单的所有适用的零件编号,我甚至根本没有在代码中定义我的域模型.

所以一方面看起来像一个糟糕的开始 – 一个非常一般的高级功能.另一方面,我觉得如果我从较低级别开始,我真的只是猜测我可能需要什么,这似乎是反TDD.

作为附注…这是怎么使用故事？

作为汇编人员

我想在制造订单上得到一个零件编号列表

所以我可以选择哪一个序列化

要真实的是,汇编人员永远不会这样说.所有汇编人员都希望在制造订单上完成操作：

作为汇编人员

我想用序列号标记零件

所以我可以在mfg订单上完成操作

这是我如何开始.假设你绝对没有这个应用程序的代码.

>定义用户故事及其带来的业务价值：“作为用户,我想提交制造订单编号和该订单的部件号列表,以便我可以将列表发送到库存系统”

>从UI开始创建一个非常简单的页面(让我们假设它的一个Web应用程序)有三个字段：标签,列表和按钮.那还够好,不是吗？用户可以复制列表并发送到inv系统.

>使用模式来设计你的设计,像MVC.

>为从UI中调用的控制器方法定义一个测试.你在这里测试控制器工作,而不是数据是正确的：Assert.AreSame(3,controller.RetrieveParts(mfgOrder).Count)

>编写控制器的简单实现,以确保返回一些东西：return new List<MfgOrder> {new MfgOrder(),new MfgOrder(),new MfgOrder()};例如,您还需要实现MfgOrder的类.

>现在你的UI正在工作！工作不正确,但工作.因此,我们期望控制器从服务或DAO获取数据.在测试用例中创建一个Mock DAO对象,并添加一个期望方法“partsDao.GetPartsInMfgOrder()”被调用.

>使用该方法创建DAO类.从控制器调用该方法.你的控制器现在完成了.

>创建单独的测试来测试DAO,最后确保从DB返回正确的数据.

>继续迭代,直到你完成所有的操作.过了一会儿,你会习惯的.

这里的主要目的是将应用程序分成很小的部分,并单独测试这些小部件.