我刚刚开始使用 BDD，正在尝试构建一个小型应用程序，这样我就可以看到它在真实环境中运行，但我无法决定什么应该是一个功能。我正在建一家小商店。
我决定“比较产品”将成为一项功能，“用户可以以访客身份结帐”将成为一项功能，但要做到这一点，我首先需要列出产品。
我的问题是，“应该有一个产品列表”应该是一个功能吗？
谢谢！
I'm just starting with BDD and I'm trying to build a small app, so I can see it working in a real environment, but I'm having trouble deciding what should be a feature. I'm building a tiny shop.
I decided that "Compare products" will be a feature and "User can checkout as guest" will be one, but to get to that, I first need to list products.
My question is, should "There should be a list of products" be a feature?
Thanks!
发布评论
评论（7）
它可能应该是一个功能，但请尝试从用户的角度来表述它。这份产品清单为他提供了什么？
It should probably be a feature, but try wording it from a user's point of view. What does this list of product offer him?
开始做 BDD 是相当困难的。唯一有助于对自己的能力和整个方法充满信心的事情是编写测试场景和执行它们的代码。我建议你不要让已经复杂和令人困惑的情况变得更加困难。选择您需要实现的任何任务，打开一个空白文本文件，并尝试使用简单的句子来解释该行为。每个句子都应以三个关键字之一开头：given、when 和 then。使用您最喜欢的 BDD 框架编写代码来解析这些句子并刺激应用程序进入启动状态（给定），执行一些命令（何时）并断言转换状态（然后）。应用程序代码可能只是从模拟开始。用逐步构建的代码逐渐替换这些模拟，并以更高的信心和质量水平发展您的应用程序。
It's pretty hard to begin doing BDD. The only thing that helps feeling confident in your abilities and the whole approach is to write test scenarios and the code that executes them. I would suggest you not to make already complex and confusing situation harder. Pick whatever task that you need to implement, open a blank text file and try to explain using simple sentences the behavior. Every sentence should start with one of three keywords: given, when and then. Using your favorite BDD framework write the code that will parse these sentences and stimulate the application to get into the start state (given), execute some commands (when) and assert the transitioned state (then). Application code may start from mere mocks. Replace gradually those mocks with gradually built code and grow your application with higher confidence and quality levels.
用户故事是一个功能。可以用格式表达的东西：
例如，
这样我就可以选择最能满足我需求的产品
作为访客
当然每个功能都必须通过一系列“Given-When-Then”场景来确认。
User story is a feature. Something that can be expressed in format:
E.g.
So that I can select a product satisfying my needs in a best way
As guest
Each feature have to be confirmed by a series of Given-When-Then scenarios of course.
您基本上是在问什么是功能。想一想，您有一个故事，一个故事描述了您（或其他相关人员）想要为您的应用程序提供的功能。通常它的形式如下： 作为用户，我想查看产品列表。您可以为这个故事添加注释，以便使其更加清晰。但接下来是具体的行为（最终你将对其进行测试）——有无数的行为符合这个故事（想想产品的观点以及呈现它们的多种方式）。在 BDD 中，您的重点是找到适合您的应用程序需求的行为（我使用应用程序而不是用户，因为有时您应该为用户做出决定） - 通过与尽可能多的人交谈，通过尝试和迭代结束了。
这就像从上到下——总是试图关注行为——越走越具体。如果您考虑一下，给定一种行为（意味着一组测试），就会有无限数量的实现。这就是为什么 BDD 的重点是通过实验和讨论来真正理解行为——总是有一定程度的自由。
You're basically asking what is a feature. Think about it, you have a story, a story describes a feature you (or other people involved) want for your app. Usually it has the form of: As a user I want to view list of products. You may add notes to this story, in order to make it more clear. But then comes the specific behaviour (that eventually you will test against) - there are infinite number of behaviours that conform to this story (think about view of products and the many ways to present them). Your focus, in BDD, is on finding the behaviour that suite your app needs (I use app and not user, because sometimes you should decide for the user) - by talking to as many people as you can, by trying stuff out and iterating it over.
It's like going from top to bottom - always trying to focus on behaviour - being more specific as you go. If you think about it, given a behaviour (meaning a set of tests) there is an infinite number of implementations. That's why the focus of BDD is to truly understand the behaviour by experimenting and talking - there is always a degree of freedom.
更重要的是弄清楚用户想要对产品列表做什么？
该功能将为用户提供一些有价值的东西。
因此，在您的情况下，它将是
More important would be to figure out what the user wants to do with the list of products?
the feature would be providing something valuable to the user.
so in your case it would be
我将功能分类为一组最小的有用故事，可以提供一些连贯的（业务）价值。
对于 BDD 框架，请参阅 http://kernowcode.wordpress.com
I would classify a feature as a minimum useful set of stories that deliver some coherent (business) value.
for BDD framework see http://kernowcode.wordpress.com
要确定需求是否是明确的功能/用户故事，您可以使用基于任务的设计/文档指南（例如 http://www.sprez.com/articles/task-documentation-design.html）。这些概念承认系统的用户想要实现特定的结果。通常，了解某些信息（例如：有哪些产品可用）只是购买/销售/构建/等过程中的一个步骤。
BDD 的一个很好的起点是编写您将在用户手册中用作章节的主题。这些主题通常是您将在软件解决方案中提供的功能。
Concordion (http://concordion.org) 是一个很好的框架，支持这种按示例进行规范的方法。请看一下“简单英语的验收测试”的描述（http://gojko.net/2009/09/01/acceptance-testing-in-plain-english-with-concordion-net/）。
To determine, if a requirement is an explicit feature / user story, you could use the guidelines of task based design / documentation (e.g. http://www.sprez.com/articles/task-documentation-design.html). Such concepts acknowledge that a user of a system wants to achieve a specific result. Usually, to know something (such as: which products are available) is only a step in the process of purchasing / selling / building / etc.
A good starting point in BDD is to write the topics you would use as chapters in your user manual. These topics are usually the features you are going to provide in your software solution.
A nice framework that supports such an approach of specification-by-example is Concordion (http://concordion.org). Please have a look at the description of “acceptance tests in plain English” (http://gojko.net/2009/09/01/acceptance-testing-in-plain-english-with-concordion-net/).