我目前的项目是重新组建一个生成序列号的现有系统,作为公司组装过程的一部分.由于查看现有系统,我对当前的流程和工作流程有一个了解.我还有一个新的要求清单,以及如何修改工作流程.
我觉得我准备好开始编写程序了,我决定强迫自己从头到尾都是做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返回正确的数据.
>继续迭代,直到你完成所有的操作.过了一会儿,你会习惯的.
这里的主要目的是将应用程序分成很小的部分,并单独测试这些小部件.
