BDD是否真的适用于UI层? [英] Is BDD really applicable at the UI layer?

问题描述

BDD是一种由内而外" 的方法，据我所知，这意味着您从了解的内容开始.您编写故事和场景，然后实现最外层的域对象，并逐步向内"和故意"发现协作者-遍历服务层，域层等.对于尚不存在的协作者，您可以对其进行嘲笑(或伪造")，直到完成为止. (我是直接从Dan North和Kent Beck那里窃取这些术语的.)

BDD is an "outside-in" methodology, which as I understand it, means you start with what you know. You write your stories and scenarios, and then implement the outermost domain objects, moving "inwards" and "deliberately" discovering collaborators as you go--down through service layers, domain layers, etc. For a collaborator that doesn't exist yet, you mock it (or "fake it") until you make it. (I'm stealing some of these terms straight from Dan North and Kent Beck).

那么，UI如何适合这个呢?

So, how does a UI fit into this?

从North的博客条目之一中借用，他将其重写为:

Borrowing from one of North's blog entries, he rewrites this:

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可以更改，并且故事(或更确切地说，故事的意图)不会中断.

He does this to eliminate language from non-relevant domains, one of which is the UI ("Name field", "Password field", "Login button"). Now the UI can change and the story (or rather, the story's intent) doesn't break.

因此，当我编写此故事的实现时，是否使用UI?最好通过Selenium测试启动浏览器并执行用户提交有效凭证"，还是直接连接到基础实现(例如身份验证服务)?顺便说一句，我正在使用 jBehave 作为我的BDD框架，但是它很容易是Cucumber，rSpec或一个数字其他人.

So when I write the implementation for this story, do I use the UI or not? Is it better to fire up a browser and execute "the user submits valid credentials" via a Selenium test, or to connect to the underlying implementation directly (such as an authentication service)? BTW, I'm using jBehave as my BDD framework, but it could just as easily be Cucumber, rSpec, or a number of others.

我倾向于不以自动化的方式测试UI，并且我对诸如Selenium之类的GUI自动化工具持谨慎态度，因为我认为测试(1)可能过于脆弱，而(2)在执行成本不高的情况下可以运行最好的.因此，我的意愿是手动测试UI的美观性和可用性，并将业务逻辑留在较低的，更易于自动化的层上. (并且可能不太可能更改图层.)

I tend not to test UI in an automated fashion, and I'm cautious of GUI automation tools like Selenium because I think the tests (1) can be overly brittle and (2) get run where the cost of execution is the greatest. So my inclination is to manually test the UI for aesthetics and usability and leave the business logic to lower, more easily automatible layers. (And possibly layers less likely to change.)

但是我愿意为此而being依.那么，BDD是否适用于UI?

But I'm open to being converted on this. So, is BDD for UI or not?

PS.我已经阅读了有关该主题的所有文章，但没有一个能真正解决我的问题. 这一个距离最近，但我我不是在谈论将用户界面分成一个单独的故事；相反，我正在谈论完全出于BDD的目的而忽略它.

PS. I have read all the posts on SO I could find on this topic, and none really address my question. This one gets closest, but I'm not talking about separating the UI into a separate story; rather, I'm talking about ignoring it entirely for the purposes of BDD.

推荐答案

大多数使用自动BDD工具的人都在UI层使用它.我已经看到一些团队将其带到下一层-控制器层或演示者层-因为他们的UI更改太频繁了.一个团队可以从其面向客户的网站上的UI和管理网站上的控制器中自动执行操作，因为如果出现问题，他们可以轻松地对其进行修复.

Most people who use automated BDD tools use it at the UI layer. I've seen a few teams take it to the next layer down - the controller or presenter layer - because their UI changes too frequently. One team automated from the UI on their customer-facing site and from the controller on the admin site, since if something was broken they could easily fix it.

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

Mostly BDD is designed to help you have clear, unambiguous conversations with your stakeholders (or to help you discover the places where ambiguity still exists!) and carry the language into the code. The conversations are much more important than the tools.

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

If you use the language that the business use when writing your steps, and keep them at a high level as Dan suggests, they should be far less brittle and more easily maintainable. These scenarios aren't really tests; they're examples of how you're going to use the system, which you can use in conversation, and which give you tests as a nice by-product. Having the conversations around the examples is more important than the automation, whichever level you do it at.

我想说的是，如果您的UI稳定，请尝试自动化，如果对您不起作用，请降低级别或确保您进行了足够的手动测试.如果您无论如何都在测试美学，那将是有帮助的(并且永远不要使用自动化来测试美学！)如果您的UI不稳定，请不要使其自动化-您只是在向可能会做的事情添加承诺.变化，在这种情况下，自动化将使工作变得更加困难.

I'd say, if your UI is stable, give automation a try, and if it doesn't work for you, either drop to a lower level or ensure you've got sufficient manual testing. If you're testing aesthetics anyway that will help (and never, ever use automation to test aesthetics!) If your UI is not stable, don't automate it - you're just adding commitment to something that you know is probably going to change, and automation in that case will make it harder.

这篇关于BDD是否真的适用于UI层?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！