如果还没有从TDD中产生设计，如何实践ATDD？

Question

尽管是非常利益相关者友好，ATDD的目标是提供一个“停止”线时，一个功能刚刚完成。这避免了在添加非重点代码(有时是无用代码)上浪费时间。

这就是为什么一些团队从建立应用程序的可移动框架开始，并通过验收测试直接指定第一个必需的特性。

让我们假设这个第一个验收测试(不代表相关的第一个验收测试，只是一个例子)：

鉴于Michael刚刚在应用程序中创建，他的状态应该留给非激活状态。

我想写我的接受测试，集中于业务逻辑(用例)，而不是处理业务规则的GUI。

因此，我的问题会是be...how写的吗？因为我甚至不知道什么是“用户”，什么是状态等等.实际上，TDD的角色不应该是出现设计，因此出现这些组件吗？

但是，如果我第一次实践TDD来出现它们，ATDD (作为一条停机线)的好处就会消失。

我认为，当项目进展顺利时，编写一些验收测试(在进入TDD周期之前)会更加一致，因为所有主要组件都已经设计好了。

总之，我应该总是在我的TDD周期之前写我的验收测试吗？

Answer 1

.难道不应该是TDD的角色来出现设计，因此出现这些组件吗？

不是的。

这是关于TDD的一个常见的误解。TDD的目的不是“发展一个设计”。TDD的目的是确保程序保持“精心设计”。TDD将迫使您创建一个可测试的API，并由此产生特定的功能需求。但它不会为你创造出你的设计。你必须自己去做。

ATDD将通过提供具体的、可测试的客户需求来帮助您设计程序。这是一种非常实用的方法:通过预先声明验收测试需求，客户已经准确地告诉了您，您的程序必须做什么才能宣告成功。

另请参阅

吉姆·科普林和鲍勃·马丁辩论TDD

鲍勃叔叔的归来 (第3页)

Answer 2

在实践中，当我从验收测试开始时，我倾向于让设计变得有点粗糙，只需要引入简单的概念版本才能取得进展。诀窍是，当你有足够多关于隐含设计的信息来重构时，才能认识到这一点。

实际上，我觉得你的第一次考试有更大的问题。您将从序列中的第一步开始，而不是系统中最重要/最有趣的特性。Michael并不真正关心用户的创建过程，所以您可以从硬编码用户开始，然后从那里开始。

Answer 3

因此，我的问题会是be...how写的吗？因为我甚至不知道什么是“用户”，什么是状态等等.实际上，TDD的角色不应该是出现设计，因此出现这些组件吗？

不清楚您所说的“不知道什么是用户”，但我认为这种大的业务概念不会在代码中凭空出现，因为TDD过程的结果，它们应该事先被知道，至少在大致上是这样的。

像领域驱动设计( Domain )这样的方法建议进行初步的协同建模会议，让领域专家和开发人员坐在一起，探索领域概念，并开始发展一种无处不在的语言。

这些对话产生的域模型的早期草图应该提供一个基本计划，让您开始进行验收测试。表示ATDD测试应该更容易，也更自然，因为您只需继续使用与以前相同的无处不在的语言来在代码中写下大的域概念。