TDD:从哪里开始第一次测试

ano*_*ous 14 tdd agile

所以我已经完成了一些单元测试,并且有编写测试的经验,但我还没有完全接受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

这是我将如何开始.让我们假设您完全没有此应用程序的代码.

  1. 定义用户故事及其带来的业务价值:"作为用户,我想提交制造订单号和该订单的部件号列表,以便我可以将列表发送到库存系统"
  2. 从UI开始.使用三个字段创建一个非常简单的页面(假设它是一个Web应用程序):标签,列表和按钮.那太好了,不是吗?用户可以复制列表并发送到inv系统.
  3. 使用模式来设计你的设计,就像MVC一样.
  4. 为从UI调用的控制器方法定义测试.你在这里测试控制器工作,而不是数据是正确的:Assert.AreSame(3, controller.RetrieveParts(mfgOrder).Count)
  5. 编写控制器的简单实现以确保返回某些内容:例如,return new List<MfgOrder>{new MfgOrder(), new MfgOrder(), new MfgOrder()};您还需要为MfgOrder实现类.
  6. 现在您的UI正在运行!工作不正常,但工作.因此,我们希望控制器从服务或DAO获取数据.在测试用例中创建一个Mock DAO对象,并添加一个期望方法"partsDao.GetPartsInMfgOrder()"被调用.
  7. 使用该方法创建DAO类.从控制器调用方法.你的控制器现在完成了.
  8. 创建一个单独的测试来测试DAO,最后确保它从数据库返回正确的数据.
  9. 继续迭代,直到你完成所有工作.过了一会儿,你会习惯的.

这里的要点是将应用程序分成很小的部分,然后单独测试这些小部件.