Статья Дэна Норта, о которой упомянул _Kevin, замечательный.
Помните, однако, что есть «истории пользователей», которые на самом деле должны быть написаны или, по крайней мере, собраны у клиента/пользователей. Это скорее «Как, я хочу, так что» рассказы типа.
Тогда есть критерии приемлемости, которые определяют, как и когда рассказ пользователя будет удовлетворен. Это похоже на то, что вы написали в своем посте: «Когда х, это должно быть».
Здесь много совпадений с тем, что я называю «системными историями» в моей системе управления проектами и «спецификациями» в своих тестах, которые определяют поведение, которое пользователь может не знать, но описывают взаимодействие между вашими классами. Системная история: «Когда 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));
}
Nevermind синтаксис тестирования, вы можете увидеть, что сама спецификация текст воплощается во имя тестового класса и имя метода. Кроме того, test/spec фактически тестирует поведение классов. Когда такие тесты проходят для простых пользовательских историй, критерии приемлемости выполнены.