L'article de Dan North mentionné par _Kevin est génial. Souvenez-vous, cependant, qu'il existe des "user stories", qui doivent être écrites ou au moins collectées auprès du client/des utilisateurs. Ceux-ci sont plus de la "En tant que, je veux, de sorte que" tapez des histoires.
Ensuite, il existe des critères d'acceptation, qui identifient comment et quand l'utilisateur sera déclaré satisfait. C'est comme ce que vous avez écrit dans votre message: "Quand x, il devrait y." Il y a beaucoup de chevauchement avec ce que j'appelle des «histoires de système» dans mon système de gestion de projet et des «spécifications» dans mes tests qui spécifient un comportement que l'utilisateur peut ne pas connaître, mais décrivent l'interaction entre vos classes. Historique du système: "Lorsque LoginHandler reçoit un identifiant et un mot de passe, il doit valider les données avec un LoginValidator." Spécification:
[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));
}
la syntaxe de Nevermind de test, vous pouvez voir que le texte de spécification elle-même est incarné dans le nom de la classe d'essai et le nom de la méthode. De plus, le test/spec teste actuellement le comportement des classes. Lorsque des tests de ce type sont passés pour des user stories simples, les critères d'acceptation ont été respectés.