提到“Kevin”的Dan North s条是巨大的。

但是,注意到有“用户故事”,这些故事实际上应当写成或至少从客户/用户收集。 以上是“我所希望的”一类故事。

然后有接受标准,确定用户故事如何和何时得到满足。 就像你在你的岗位上写的:“在X时,它应该......”。

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

永远不会把测试合成物污染,你可以看到,规格本身体现在测试类别名称和方法名称中。 此外,测试/检查实际上正在测试这些班级的行为。 当像这份简单的用户故事通行证一样进行测试时,就达到了接受标准。