我刚开始学习BDD,正在尝试构建一个小应用程序,以便在实际环境中看到它的工作情况,但我很难决定什么应该成为一个特性。我正在构建一个微型商店。
我决定“比较产品”将是一个特性,“用户可以作为访客结账”也将是一个特性,但是要实现这一点,我首先需要列出产品。
我的问题是,“应该有产品列表”是否应该成为一个特性?
谢谢!
我刚开始学习BDD,正在尝试构建一个小应用程序,以便在实际环境中看到它的工作情况,但我很难决定什么应该成为一个特性。我正在构建一个微型商店。
我决定“比较产品”将是一个特性,“用户可以作为访客结账”也将是一个特性,但是要实现这一点,我首先需要列出产品。
我的问题是,“应该有产品列表”是否应该成为一个特性?
谢谢!
这可能应该成为一个功能,但请从用户的角度来表述。这个产品列表能为他提供什么?
开始进行BDD是相当困难的。唯一能帮助你增强信心并理解整个方法的是编写测试场景和执行它们的代码。我建议您不要让已经复杂混乱的情况更加困难。选择需要实现的任务,打开一个空白文本文件,尝试使用简单的语句来解释其行为。每个语句都应以以下三个关键字之一开始:given, when 和 then。使用您喜欢的BDD框架编写代码,解析这些语句并刺激应用程序进入起始状态(给定),执行某些命令(when)并断言转换后的状态(then)。应用程序代码可以从纯模拟开始。逐步将这些模拟替换为逐步构建的代码,并以更高的信心和质量水平发展您的应用程序。
更重要的是弄清楚用户想要用产品列表做什么?该功能将为用户提供有价值的东西。因此在您的情况下,它将是:
用户故事是一种功能。可以用以下格式表达:
例如:
以便我可以选择最符合我的需求的产品
作为访客
当然,每个功能都必须通过一系列的Given-When-Then场景进行确认。
为了确定需求是否是明确的功能/用户故事,您可以使用基于任务的设计/文档编写指南(例如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/)。