使用 Cucumber 编写 Rails 应用程序的功能需求文档
根据 BDD，在新的 Rails 项目开始时使用 Cucumber 特性和场景来编写功能需求文档是一个好主意吗？
In the light of BDD, would it be a good idea to use Cucumber features and scenarios to write up the functional requirements document at the start of a new Rails project?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
可能不会。这是 BDUF 的一个例子 (http://en.wikipedia.org/wiki/Big_Design_Up_Front)。
您不太可能预先想到所有场景。您应该将高级需求拆分为功能，以帮助估计它们并确定其优先级，但将详细的场景保留在准备开始实现每个功能之前。
Probably not. This would be a case of BDUF (http://en.wikipedia.org/wiki/Big_Design_Up_Front).
It's unlikely you'll be able to think of all the scenarios up front. You should split the high-level requirements into features to help estimate and prioritise them, but leave the detailed scenario writing to just before you're ready to begin implementing each feature.
如果你不是做出所有决定的人，而有人认为你需要这些，
那么它似乎是比 MS Word 更好的选择。
我实际上加入了一个具有一百万个未实现功能的项目，
所以理论上我们有大量的集成测试，但没有
其中已实际实施。
几个月后，我们仍然有一些，
在这样的环境中工作真的很困难
一切都立刻失败了。
最好一次只进行 1 个失败的步骤。
我还认为功能应该由应用程序开发人员编写
了解用户流量的实际情况。
我喜欢企业或客户以对话的方式向我解释事情，
一次一点，而不是他们一万字统治世界的全部愿景，
我会把它留到睡觉时用。
If you are not the one making all the decisions and someone thinks you need these,
then it might appear to be a better choice than MS word.
I actually joined a project with a million un-implemented features,
so we had loads of integrations test in theory, just none
of them were actually implemented.
Its months later and we still have some,
its really difficult working in an environent where
everything is failing at once.
Its better to have 1 failing step at a time.
I also think feautures should be written by application developers who
understand user flow realities.
I like the business or client to explain stuff to me in a conversational syle,
a bit at a time, not their entire vision for world domination in 10 000 words,
I will keep that for bed time.