RSpec“意识形态”问题：如何区分测试描述和实现
阅读大量有关行为驱动测试的材料。事实上，正如所述（例如）这里< /a>，规范的代码应该非常可读、简短且直接。
现在我有一个问题：假设有两种团队成员：一种是开发人员，另一种是测试人员（QA）。如果没有 describe 和 it 存根（其中所有 it 都标记为待处理？因此，QA 可能想要创建这样一个测试计划并将其传递给开发人员以进行正确的实施。
几天后，测试人员（或产品经理）想要查看测试结果。但是...里面有一个地狱般的代码。
因此，问题：有没有办法在 RSpec 中区分行为规范和实现？我可以发明很多方法，但在发明轮子之前，我宁愿坚持一些常见的、经过验证的、众所周知的实践。
Read a lot of materials regarding the behavior-driven testing. Indeed, as it is stated (for example) here, the specs' code should be extremely readable, short and straightforward.
Now I have a question: suppose there are two kinds of team players: one is the developer, the other is a tester (QA). What would be the best test plan if not describe and it stubs, where all the its are marked as pending? So, the QA might want to create such a test plan and pass it to the developer for the proper implementation.
After a few days, the tester (or product manager) wants to have a look on the tests. But... there is a hell of a code in there.
Hence, the question: is there a way to separate between the behavior specification and implementation in RSpec? I can fabricate a plenty of methods, but before inventing the wheel, I would rather prefer to stick to some common, proven and well-known practice.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
根据 The RSpec Book RSpec 是开发人员的内容他们在内部进行管理，但Cucumber是生产经理和业务人员可以看到的。将 RSpec 视为代码覆盖率的内部工具，以查看对象的内部行为：模型、控制器、视图。其他团队成员也可以看到 Cucumbers 覆盖的整体图片
as according to The RSpec Book RSpec is what developers manage for them internally, but Cucumber is what production manager and business can see. Think about RSpec as like internal tool to code coverage to see the objects internal behaviour: models, controllers, views. Other team members can see overall pictures that Cucumbers covers as well