我即将第一次使用 BDD(行为驱动设计),并试图习惯这种不同的解决问题的方式。
您能否提供一些您会为使用 BDD 的简单登录应用程序编写的故事/场景?
例如,从我读过的内容来看,这似乎很好:
当用户输入无效的用户名/密码时,会显示错误消息。
相对于:
通过在数据库中搜索匹配记录来验证 ID 和密码。
我即将第一次使用 BDD(行为驱动设计),并试图习惯这种不同的解决问题的方式。
您能否提供一些您会为使用 BDD 的简单登录应用程序编写的故事/场景?
例如,从我读过的内容来看,这似乎很好:
当用户输入无效的用户名/密码时,会显示错误消息。
相对于:
通过在数据库中搜索匹配记录来验证 ID 和密码。
Dan North 在写故事方面有一些很好的建议。“丹·诺斯——故事里有什么?”
我还会看看围绕Cucumber所做的一些工作,因为他们花了很多时间思考如何以可理解和可执行的方式编写这些故事。
_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));
}
不用管测试语法,你可以看到规范文本本身就体现在测试类名和方法名中。此外,测试/规范实际上是在测试类的行为。当像这样的测试通过简单的用户故事时,就满足了验收标准。
我在这里找到了一个很棒的演讲https://skillsmatter.com/skillscasts/2446-bdd-as-its-meant-to-be-done (注意,您需要创建一个帐户才能观看视频)