2

我需要 BDD/ATTD/规范方面的专家的建议。（对不起，一篇长文，我不知道如何用更少的文字表达问题）

问题描述

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

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

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

我们如何看到它解决了

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

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

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

问题

那么，有人可以建议一种管理无法达到规范的低级别需求的良好做法吗？

4

1 回答 1

2

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

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

于 2012-10-18T22:08:16.527 回答