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