如何在BDD中编写故事/场景(行为驱动设计)

时间:2009-05-28 19:22:46

标签: bdd scenarios user-stories

我将第一次使用BDD(行为驱动设计),并且我正在尝试习惯这种处理问题的不同方式。

您是否可以提供一些故事/场景,您可以使用BDD说出一个简单的登录应用程序?

例如,根据我的阅读,似乎很好:

  

当用户输入无效的用户ID /密码时,则显示错误   消息。

相反:

  

通过搜索匹配的记录来验证ID和密码   数据库中。

3 个答案:

答案 0 :(得分:13)

Dan North在写故事方面有一些很好的建议。 "Dan North- What's in a Story?"

我还会看一下围绕Cucumber所做的一些工作,因为他们花了很多时间思考如何以可理解和可执行的方式编写这些故事。

答案 1 :(得分:7)

Dan North的文章_Kevin提到的很棒。

但请记住,有“用户故事”,实际上应该写入或至少从客户端/用户收集。这些更像是“作为一种,我想要的,所以”类型的故事。

然后有接受标准,用于确定用户故事将如何以及何时被称为满意。这就像你在帖子中写的那样:“当x,它应该是y。”

在我的项目管理系统中我称之为“系统故事”和我的测试中的“规范”有很多重叠,这些规范指定了用户可能不知道的行为,但描述了类之间的交互。 系统故事:“当LoginHandler获得登录名和密码时,它应该使用LoginValidator验证数据。” 规格:

[TestFixture]
public class When_the_login_handler_is_given_a_login_and_password
{
   constant string login = "jdoe";
   constant string password = "password";
   static LoginValidator loginValidator;

   context c = () => loginValidator = an<ILoginValidator>;

   because b = () => sut.Validate(login, password);

   it should_validate_the_data_with_a_LoginValidator =
      () => loginValidator.was_told_to(x => x.DoValidation(login, password));
}

没关系测试语法,您可以看到规范文本本身体现在测试类名称和方法名称中。此外,test / spec实际上是测试类的行为。当这样的测试通过简单的用户故事时,已经达到了验收标准。

答案 2 :(得分:0)

我在这里找到了一个很棒的演讲https://skillsmatter.com/skillscasts/2446-bdd-as-its-meant-to-be-done (注意,您需要创建一个帐户才能观看视频)