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)在执行成本最高的地方运行.所以我倾向于手动测试用户界面的美学和可用性,并将业务逻辑留给更低,更容易实现自动化的层.(可能不太可能改变层数.)
但我愿意接受这个转变.那么,BD的BDD是不是？
PS.我已经阅读了关于这个主题的所有帖子,而且没有一个真正解决我的问题. 这个最接近,但我不是在谈论将UI分成一个单独的故事; 相反,我说的是完全出于BDD的目的忽略它.
Lun*_*ore 17
大多数使用自动BDD工具的人在UI层使用它.我见过一些团队把它带到下一层 - 控制器或演示者层 - 因为他们的UI变化太频繁了.一个团队在其面向客户的站点和管理站点上的控制器上从UI自动化,因为如果某些东西被破坏,他们可以轻松地修复它.
大多数情况下,BDD旨在帮助您与利益相关者进行清晰,明确的对话(或帮助您发现存在歧义的地方!)并将语言带入代码中.对话比工具重要得多.
如果您在编写步骤时使用业务使用的语言,并按照Dan的建议将其保持在较高水平,那么它们应该不那么脆弱且易于维护.这些场景不是真正的测试; 它们是您将如何使用系统的示例,您可以在对话中使用该系统,并将测试作为一个不错的副产品.围绕示例进行对话比自动化更重要,无论您采用哪种级别.
我会说,如果您的用户界面稳定,请尝试自动化,如果它不适合您,请降低到较低级别或确保您有足够的手动测试.如果你正在测试美学,那将有所帮助(并且永远不会使用自动化测试美学!)如果你的用户界面不稳定,不要自动化它 - 你只是在你知道可能会去的东西上添加承诺改变,在这种情况下自动化将使其变得更难.