Подтвердить что ты не робот

Как писать рассказы/сценарии в BDD (Behavior Driven Design)

Я собираюсь использовать BDD (Behavior Driven Design) в первый раз и пытаюсь привыкнуть к этому другому способу приближения к проблеме.

Можете ли вы рассказать несколько историй/сценариев, которые вы могли бы написать, например, для простого приложения входа в систему, используя BDD?

Например, из того, что я прочитал, кажется, что это хорошо:

Когда пользователь вводит недопустимый идентификатор пользователя/пароль, тогда отображает ошибку сообщение.

В отличие от:

Подтвердите идентификатор и пароль, выполнив поиск соответствующей записи в базы данных.

4b9b3361

ОТВЕТЫ

Ответ 1

У Дэна Севера есть отличный совет по написанию историй. "Дэн Норт - что в истории?"

Я также хотел бы взглянуть на некоторые из работ, выполняемых вокруг Cucumber, поскольку они потратили много времени на размышления о том, как писать эти истории понятным и исполняемым образом.

Ответ 2

Дэн Северная статья, о которой упоминал Кевин, велик.

Помните, однако, что есть "истории пользователей", которые на самом деле должны быть написаны или, по крайней мере, собраны у клиента/пользователей. Это скорее "Истории типа" Как, я хочу, так что ".

Тогда есть критерии приемлемости, которые определяют, как и когда пользовательская история будет считаться удовлетворительной. Это похоже на то, что вы написали в своем посте: "Когда 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));
}

Не обращайте внимание на синтаксис тестирования, вы можете видеть, что сам текст спецификации воплощен в имени и имени тестового класса. Кроме того, test/spec фактически тестирует поведение классов. Когда тесты, подобные этому, проходят для простых пользовательских историй, критерии приема были выполнены.