代码之家 › 专栏 › 技术社区 › anonymous

TDD:从何处开始第一次测试[关闭]

agile tdd

15

anonymous · 技术社区 · 16 年前

我目前的项目是重新设计一个现有的系统,作为公司组装过程的一部分生成序列号。通过查看现有系统,我对当前流程和工作流程有了了解。我还有一个新需求列表,以及它们将如何修改工作流程。

我觉得我已经准备好开始写程序了,我决定强迫自己最终从头到尾做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);

一方面,这看起来是一个糟糕的开始——一个非常普通的高级函数。另一方面,我觉得如果我从一个较低的层次开始,我只是在猜测我可能需要什么,这似乎是反TDD的。

作为旁注。。。这就是你使用故事的方式吗?

作为装配工我想得到一份生产订单上的零件号清单这样我就可以选择序列化哪一个了

作为装配工我想用序列号标记零件

4 回复 | 直到 16 年前

1

16

Eduardo Scoz 16 年前

以下是我将如何开始。假设您完全没有此应用程序的代码。

从UI开始。创建一个非常简单的页面(假设它是一个web应用程序),包含三个字段:标签、列表和按钮。这很好,不是吗?用户可以复制列表并发送到inv系统。
使用模式作为设计的基础,如MVC。
Assert.AreSame(3, controller.RetrieveParts(mfgOrder).Count)
编写控制器的简单实现,以确保返回某些内容: return new List<MfgOrder>{new MfgOrder(), new MfgOrder(), new MfgOrder()};
现在你的UI工作了!工作不正常,但正在工作。因此,让我们期待控制器从服务或DAO获取数据。在测试用例中创建一个模拟DAO对象,并添加调用方法“partsDao.GetPartsInMfgOrder()”的期望。
使用该方法创建DAO类。从控制器调用该方法。您的控制器现在完成。
继续迭代,直到完成所有操作。过一会儿,你就会习惯的。

2

3

Gishu 16 年前

这是一个非常好的开始测试。通过这一点,您可以定义预期的行为——它应该如何工作。现在,如果你觉得自己吃了一口比你想吃的大得多的东西。。您可以暂时忽略此测试,并编写一个更细粒度的测试,将部分或至少中途删除。然后是其他的测试,让你朝着第一个大考通过的目标前进。每一步都进行红-绿重构。

小测试,我认为意味着你不应该在一次测试中测试很多东西。e、在我用这些参数调用了Method1()、Method2()和Method3()之后,g是state1、state2和state3中的组件D.A、B和C。每个测试应该只测试一件事。你可以搜索优秀测试的质量。但我认为你的测试是一个小测试,因为它是 简短且专注于一项任务

使现代化 :作为一个尝试建议(来自贝克的书),你可能想坐下来,在一张纸上列出SUT的单线测试列表。现在您可以选择最简单的(您有信心能够完成的测试)来建立信心。或者你可以尝试一个你有80%自信但有一些灰色区域(也是我的选择)的方法,因为这将帮助你在学习过程中了解SUT。保留那些你不知道如何进行到底的。。。希望在容易的事情完成时,情况会变得更清楚。当它们变成绿色时,一个接一个地把它们去掉。

3

1

JB King 16 年前

我认为你有一个很好的开始,但不是这样认为的。这个应该产生更多测试的测试对我来说完全有意义,就好像你仔细想想,你知道生产订单号或零件号是什么吗?你必须构建那些可能导致其他测试的测试,但最终你会进行一些小测试,我相信。

作为一个用户,我希望提交一个生产订单号,并收到该订单物料清单的可序列化零件号列表

4

1

cwap 16 年前

好吧,好吧,你碰到了我第一次尝试TDD时碰到的墙:)

从那以后,我放弃了它,仅仅是因为它使得重构成本太高——而且我在开发的初始阶段往往会进行大量重构。

我发现TDD最受监督和最重要的方面之一是,它迫使您在实际实现类接口之前定义类接口。当您需要将所有零件组装成一个大产品(嗯,组装成子产品)时,这是一件非常好的事情。在编写第一个测试之前,您需要做的是在编码之前准备好您的域模型、部署模型,最好是一大块类图——这仅仅是因为您需要识别不变量、最小值和最大值等,然后才能测试它们。您应该能够在设计的单元测试级别上识别这些。

Soo,根据我的经验(不是一些喜欢将真实世界的类比映射到OO:P的作者的经验),TDD应该是这样的:

根据需求规范创建您的部署图(ofc,没有什么是一成不变的)
创建或修改域模型以包含此故事
识别测试向量。
根据在步骤4中创建的接口创建测试
测试测试(!)。这是非常重要的一步。。
去和你的同事喝杯啤酒:)