我需要一个BDD / ATTD /规范专家的建议。 （对不起，长篇文章，我不知道如何用更少的文字表达问题）
问题描述
我们一直致力于中型项目约1年。 该团队使用由验收测试驱动的基于流程的流程（以详细测试用例的形式编写）。
现在，随着需求的发展，我们开始遇到这些测试的可维护性问题。
我们如何看待它解决
为了解决这个问题，我们将把测试转换为可执行规范。 我读过的所有书籍/文章（例如Gojko Adzic的示例规范）都建议我们不要使用低级别细节重载规格，而这些细节告诉 产品应该实施，而不是产品应该做的 来满足业务预期。
这似乎是合理的，因为规范可能更具可读性和可维护性，并且反映了业务目标，而不是过度指定时的软件设计。 但是，这些低级别的细节不能被丢弃 - 尽管业务用户没有明确询问它们，但它们仍然是可以预料到的。例如，如果用户按下“处理按钮”，最好禁用它，并且在处理完成之前启用“取消按钮”。这样的细节似乎在规范中是不必要的，但是客户要接受应用程序是必需的。
我们在每个级别上使用（A）TDD并且仅用于编写代码以进行测试通过。现在，我们将提供更抽象的可执行规范，而不是详细测试，而不知道在哪里放置那些低级细节。
问题
那么，是否有人建议管理不符合规范的低级要求的良好实践？
答案 0 :(得分：2)
我认为将步骤描述为When user presses 'Process button'肯定告诉我们如何系统应该实施，而不是描述什么产品应该为业务做什么。我们从这一步知道了什么？只有我们在UI上的某个地方有按钮（不是链接，而不是其他控件），其上有文本Process。关于商业没什么。更糟糕的是 - 它非常脆弱。如果您将按钮的文本更改为Start，则此步骤将无效。如果更改控件类型，则相同。
点击按钮不是业务目标。那么，如何描述业务目标呢？我认为When user starts processing bills是对步骤的良好定义。如果更改UI，此行为将保持不变。它不再脆弱了。只有执行步骤才会改变。