24

BDD 是一种“由外而内”的方法，据我所知，这意味着你从你所知道的开始。你编写你的故事和场景，然后实现最外层的领域对象，在你通过服务层、领域层等的过程中“向内”和“有意识地”发现合作者。对于一个还不存在的合作者，你嘲笑它（或“伪造它”）直到你成功。（我直接从 Dan North 和 Kent Beck 那里窃取了其中的一些术语）。

那么，UI 是如何融入其中的呢？

借用 North 的一篇博客文章，他重写了以下内容：

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？

PS。我已经阅读了关于这个主题的所有帖子，但没有一个能真正解决我的问题。 这个最接近，但我不是在谈论将 UI 分成一个单独的故事。相反，我说的是出于 BDD 的目的而完全忽略它。

4

3 回答 3

17

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

大多数情况下，BDD 旨在帮助您与利益相关者进行清晰、明确的对话（或帮助您发现仍然存在歧义的地方！）并将语言带入代码中。对话比工具重要得多。

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

我想说，如果您的 UI 稳定，请尝试自动化，如果它不适合您，请降低到较低级别或确保您有足够的手动测试。如果您无论如何都在测试美学，这将有所帮助（并且永远不要使用自动化来测试美学！）如果您的 UI 不稳定，请不要自动化它 - 您只是对您知道可能会发生的事情添加承诺变化，在这种情况下，自动化将使其变得更加困难。

于 2012-04-27T18:44:59.863 回答
2

我自己是 BDD 的新手，但我发现 cuke4ninja 网站可以在这方面提供帮助。他们的建议（我的解释）是您的步骤定义是高级且与 UI 无关的，它调用“工作流”类，该类将“单击此按钮”、“填充此字段”等详细信息分组到捕获的方法中正在测试的工作流，它调用一个“屏幕驱动程序”类来处理该特定屏幕的 UI 自动化。这样，所有 UI 自动化代码都从步骤定义中抽象出来并位于一个位置，如果 UI 发生变化，您只需更改“屏幕驱动程序”中的代码，而不是所有多个测试。这是讨论它的相关页面。

于 2013-05-08T21:51:36.223 回答
1

BDD 描述了什么？

在遵循行为驱动开发 (BDD) 的团队中，验收标准（又称规则）应该描述“系统做什么”而不是“系统如何做”。

那么，在遵循 BDD 的团队中，UI/UX 细节在哪里捕获？

在使用 BDD 的团队中，用户界面 (UI) 和用户体验 (UX)（按钮、点击、动画等）层详细信息不应作为文本格式的接受标准（又名规则）包含在工单（例如已签发使用软件票务工具，例如 JIRA、GitLab 等）。相反，它们应该包含在设计屏幕中（线框、用户旅程、单个屏幕等）。例如，文本注释可以嵌入带有注释的设计屏幕上，或者只是作为屏幕旁边的注释。

于 2019-01-21T08:10:50.997 回答