所以我已经完成了一些单元测试,并且有编写测试的经验,但我还没有完全接受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);
Run Code Online (Sandbox Code Playgroud)
阅读Kent Becks的示例书,他谈到了选择小测试.这看起来像一个非常大的黑盒子.它将需要一个mfg订单存储库,我必须抓取产品结构树以查找此mfg订单的所有适用的部件号,我甚至根本没有在代码中定义我的域模型.
所以一方面看起来像一个糟糕的开始 - 一个非常普遍的高级功能.另一方面,我觉得如果我从较低的水平开始,我真的只是猜测我可能需要什么,这似乎是反TDD.
作为旁注......这就是你如何使用故事?
作为汇编程序,我想获得一个mfg订单上的部件号列表,以便我可以选择要序列化的部件号
说实话,汇编人永远不会这么说.所有汇编程序想要的是完成对mfg命令的操作:
作为汇编程序,我想用序列号标记部件,以便我可以完成对mfg订单的操作
Edu*_*coz 16
这是我将如何开始.让我们假设您完全没有此应用程序的代码.
Assert.AreSame(3, controller.RetrieveParts(mfgOrder).Count) return new List<MfgOrder>{new MfgOrder(), new MfgOrder(), new MfgOrder()};您还需要为MfgOrder实现类.这里的要点是将应用程序分成很小的部分,然后单独测试这些小部件.