举例说明：如何管理低级细节[关闭]答案

【问题标题】：Specification By Example: how to manage low level details [closed]举例说明：如何管理低级细节[关闭]
【发布时间】：2012-10-18 21:38:53
【问题描述】：

我需要 BDD/ATTD/规范方面的专家的建议，例如。（不好意思写了长篇，不知道怎么用更少的词来表达问题）

问题描述

我们在一个中型项目上工作了大约 1 年。团队正在使用由验收测试驱动的基于流程的流程（以详细的测试用例的形式编写）。

现在，随着需求的发展，我们开始遇到这些测试的可维护性问题。

它们（非常）难以阅读，绝对不能用作产品规范
需求的微小变化会导致很多天重构，因为测试与实现细节过于耦合

我们认为它是如何解决的

为了解决这个问题，我们将把我们的测试转换成可执行的规范。我读过的所有书籍/文章（例如 Gojko Adzic 的规范示例）都建议我们不要使用低层次的细节来重载规范，而这些细节告诉我们如何产品应该实施而不是产品应该做什么来满足业务期望。

这似乎是合理的，因为规范可能更具可读性和可维护性，并且在没有过度指定的情况下反映业务目标而不是软件设计。然而，这些低级别的细节不能被丢弃——尽管业务用户没有明确要求它们，但它们仍然是预期的。例如，如果用户按下“处理按钮”，最好禁用它并启用“取消按钮”，直到处理完成。这样的细节在规范中似乎是不必要的，但应用程序要被客户接受是必需的。

我们在每个级别都使用 (A)TDD，并且习惯于编写代码只是为了通过测试。现在，我们将拥有更多抽象的可执行规范，而不是详细的测试，并且根本不知道将这些低级细节放在哪里。

问题

那么，有人可以提出一个管理无法符合规范的低级别需求的良好做法吗？

【问题讨论】：

标签： bdd acceptance-testing specifications

【解决方案1】：

我认为将步骤描述为When user presses 'Process button' 绝对是告诉我们应该如何实施系统，而不是描述产品应该为业务做什么。从这一步我们知道了什么？只是我们在 UI 上的某处有按钮（不是链接，不是其他控件），上面有文本 Process。与商业无关。更糟糕的是——它非常脆弱。如果您将按钮的文本更改为Start，此步骤将无效。如果您更改控件类型，则相同。

点击按钮不是业务目标。那么，如何描述业务目标呢？我认为When user starts processing bills 是对步骤的良好定义。如果您更改 UI，此行为将保持不变。它不再脆了。只有 step 的实现会改变。

【讨论】：

谢谢，但您的帖子更像是重复了我所说的内容-过度指定的规范不是一个好主意-但没有回答我的问题。这样的要求仍然需要检查（因为这是一个好的应用程序所期望的常识）。如果它不在规范中，那么它可能会在测试执行阶段手动测试（然后将成为手动回归套件的一部分）——这也不是我们想要的。我们是否应该为 UI 交互和模型保留一个单独的规范？我们应该在可执行规范后面的单元测试级别或测试自动化层检查这些东西吗？
@olldman 实际上我指出与 UI 相关的细节应该转到步骤的实现（例如，如果您使用 Speclfow 详细信息将转到步骤定义文件）。当领域专家查看场景时，会看到他是When user starts processing bills 的领域专家，而不是 UI 领域的工作人员。我建议你阅读这篇关于 dannorth.net/2011/01/31/whose-domain-is-it-anyway 主题的精彩 Dan North 文章
我想我开始明白你的意思了。我仍然有点担心的是，规范不仅适用于领域专家，而且适用于将要实现该功能的人。在您的项目中，您会将这些细节留给开发人员来处理吗？不应该在别处指定吗？
@olldman 我认为开发人员的技术水平足以阅读步骤的定义 :) 因此，当您拥有步骤 When user starts processing bills 时，您将转到步骤定义并开始设计您的应用程序。在您遇到此业务场景之前，您没有按钮 Process。因此，您从代码开始，该代码在您在Given 步骤中设计的某个表单/页面上按下不存在的按钮。在您针对此业务需求定义 done 的含义后，开发人员开始实施步骤。他们将有细节，应该实施（在步骤定义中）。