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. 作为附注…这是怎么使用故事? 作为汇编人员 要真实的是,汇编人员永远不会这样说.所有汇编人员都希望在制造订单上完成操作: 作为汇编人员
这是我如何开始.假设你绝对没有这个应用程序的代码.
>定义用户故事及其带来的业务价值:“作为用户,我想提交制造订单编号和该订单的部件号列表,以便我可以将列表发送到库存系统” 这里的主要目的是将应用程序分成很小的部分,并单独测试这些小部件. (编辑:李大同) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |