BDD真的适用于UI层吗？

Question

BDD是一种“从外到内”的方法学，按照我的理解，这意味着你从你所知道的开始。您编写您的故事和场景，然后实现最外面的领域对象，“向内”移动，并“刻意”地发现协作者--通过服务层、领域层等向下移动。对于一个还不存在的协作者，您会嘲弄它（或“伪造它”），直到您创建它为止。（我直接从Dan North和Kent Beck那里偷来一些术语）。

那么，一个UI是如何适应这个的呢？

从诺斯的一篇博客文章中，他重写了以下内容：

Given an unauthenticated user
When the user tries to navigate to the welcome page
Then they should be redirected to the login page
When the user enters a valid name in the Name field
And the user enters the corresponding password in the Password field
And the user presses the Login button
Then they should be directed to the welcome page

Given an unauthenticated user
When the user tries to access a restricted asset
Then they should be directed to a login page
When the user submits valid credentials
Then they should be redirected back to the restricted content

他这样做是为了从非相关域中消除语言，其中之一是UI（“名称字段”、“密码字段”、“登录按钮”）。现在UI可以改变，故事（或者更确切地说，故事的意图）不会中断。

那么当我为这个故事编写实现时，我是否使用UI？是启动浏览器并通过Selenium测试执行“用户提交有效凭据”更好，还是直接连接到底层实现（如身份验证服务）更好？顺便说一句，我使用jBehave作为我的BDD框架，但它也可以是Cucumber、rSpec或许多其他框架。

我倾向于不以自动化的方式测试UI，我对Selenium这样的GUI自动化工具很谨慎，因为我认为测试（1）可能过于脆弱，(2)在执行成本最大的地方运行。因此，我倾向于手动测试UI的美观性和可用性，而将业务逻辑留给更低的、更容易自动化的层。（可能是不太可能发生变化的层。）

但我愿意在这件事上改变信仰。那么，BDD到底是不是用于UI呢？

附注：我已经看了所有的帖子，所以我可以找到关于这个话题，但没有一个真正解决我的问题。这一个是最接近的,但我不是在讨论将UI分离到一个单独的故事中；相反，我说的是完全为了BDD的目的而忽略它。

Answer 1

大多数使用自动化BDD工具的人在UI层使用它。我见过一些团队将其转移到下一层--控制器或演示者层--因为他们的UI变化太频繁了。一个团队从面向客户的站点的UI和管理站点的控制器实现了自动化，因为如果有什么东西坏了，他们可以很容易地修复它。

BDD的主要目的是帮助您与涉众进行清晰、明确的对话（或者帮助您发现仍然存在歧义的地方！）并将语言导入代码。对话比工具重要得多。

如果您使用业务部门在编写步骤时使用的语言，并按照Dan的建议将它们保持在较高的级别，则它们应该远没有那么脆弱，更容易维护。这些场景并不是真正的测试；它们是如何使用该系统的例子，可以在对话中使用，并作为一个很好的副产品提供测试。围绕示例进行对话比自动化更重要，无论您在哪一个级别进行对话。