您如何处理在 BDD 故事中添加诸如 Devise 身份验证之类的内容？
如果您有一组 BDD 场景，例如：
- 用户应该能够注册
- 用户应该能够登录
- 用户应该能够重置密码
等，通常您编写第一个场景，然后编写代码使其通过，然后重构。
但是，如果您使用像 Devise 这样的东西，一旦正确安装和配置，它就会立即为您提供所有这些功能，那么最佳实践是什么？因为，如果您编写第一个测试并配置 Devise 以使测试通过，那么您编写的其他测试应该自动通过，而之前不会失败。或者，在 BDD 工作流程中，测试首先失败并不是严格必要的，我应该为测试通过而感到高兴？
If you have a set of BDD scenarios like:
- User should be able to register
- User should be able to login
- User should be able to reset password
etc., normally you write the first scenario, then write the code to make it pass, and then refactor.
But if you use something like Devise, which, once correctly installed and configured, gives you all these features at once, what is the best practice for that? Because, if you write the first test and configure Devise so that the test passes, the other tests that you write should automatically pass without having failed before. Or is having the tests fail first not strictly necessary in a BDD workflow, and I should just be happy that the tests pass?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
使用 BDD，您应该专注于为用户或利益相关者提供的价值。登录并不是真正有价值，所以我会先给他们一些登录的东西。
然后场景就会变得简单，要么：
要么
登录没有价值，我很抱歉我是前几年使用它作为 BDD 示例的人之一。除非需要，否则不要登录，当然也不要先编写代码。
只有当我不信任第三方应用程序时，我才会为它们编写场景，在这一点上，是的，它们可能会失败。也许最好只是在您自己有价值的场景中使用它们。
With BDD, you should focus on the value you're providing to your users or stakeholders. Logging in isn't really valuable, so I'd give them something to log in for first.
Then the scenarios become easy, either:
or
Logging in has no value, and I apologise for being one of the people who's used that as a BDD example in previous years. Don't log in unless you need to, and certainly don't code it first.
I'd write scenarios for my 3rd party apps only if I didn't trust them, at which point, yes, they might fail. Probably better to simply use them in your own valuable scenarios.