当前位置：文江博客话题详情

如何用 BDD（行为驱动设计）编写故事/场景

发布于 2024-07-23 06:04:27 字数 281 浏览 6 评论 0原文

我即将第一次使用 BDD（行为驱动设计），并试图习惯这种不同的解决问题的方式。

您能否提供一些您会为使用 BDD 编写的简单登录应用程序编写的故事/场景？

例如，从我读到的内容来看，这似乎很好：

当用户输入无效的用户名/密码时，显示错误消息。

相对于：

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

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

飞烟轻若梦 2024-07-30 06:04:28

丹·诺斯（Dan North）对写故事有一些极好的建议。 “Dan North- 故事中有什么？”

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

回复收藏 0 原文

安人多梦 2024-07-30 06:04:28

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

但请记住，存在“用户故事”，实际上应该编写或至少从客户/用户那里收集。这些更多的是“作为一个，我想要，所以”类型的故事。

然后是验收标准，它确定如何以及何时满足用户故事。这就像您在帖子中所写的：“当 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));
}

不要介意测试语法，你可以看到规范文本本身就体现在测试类名和方法名中。此外，测试/规范实际上是在测试类的行为。当简单的用户故事通过这样的测试时，就满足了验收标准。

Dan North's article that _Kevin mentioned is great.

Remember, though, that there are "user stories," which should actually be written or at least collected from the client/users. These are more of the "As a , I want , so that " type stories.

Then there are acceptance criteria, which identify how and when the user story will be said to be satisfied. That is like what you have written in your post: "When x, it should y."

There is a lot of overlap here with what I call "system stories" in my project management system and "specifications" in my tests which specify behaviour that the user may not be aware of, but describe interaction between your classes.
System story: "When the LoginHandler is given a login and password, it should validate the data with a LoginValidator."
Specification:

[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));
}

Nevermind the testing syntax, you can see that the specification text itself is embodied in the test class name and method name. Furthermore, the test/spec is actually testing the behaviour of the classes. When tests like this pass for simple user stories, the acceptance criteria has been met.

回复收藏 0 原文