Какие контексты мы должны включить в сценарий?
Мне кажется, это помогает думать о сценариях не как о тестах, а как о живой документации, которая помогает проиллюстрировать, как работает система и почему это ценно.
Если вы можете сказать, что пользователь не заблокирован и не отключен в первом сценарии, вам не нужно включать эти шаги.
Для чего-то вроде входа в систему с активной, активированной учетной записью это очевидно, но это может быть не то, что для трейдера, который находится в пределах своих торговых ограничений, или сердцебиение плода, работающее с нормальной скоростью, или комментарий, который не т еще не достигли порога отчетности. Вы можете решить, следует ли включать такие контексты прагматично.
Я предпочитаю перемещать документацию, которая не меняет или меняется не очень часто, как основные понятия домена, за пределами сценариев. Возможно, это может быть в начале файла сценария или в вики команды где-то, что новые столяры могут прочитать, прежде чем они закодируют. Это не должно быть в сценарии.
(Очевидно, вам нужно будет включить контексты, которые вызывают сбой в любом сценарии сбоя!)
А как насчет побочных эффектов и других результатов?
Все результаты, которые имеют значение, делают это, потому что в какой-то момент они становятся видимыми или имеют эффекты вне системы, чье поведение рассматривается в сценарии.
Например, когда я получаю деньги из банкомата, мой счет также списывается. Я мог бы не видеть это как часть поведения, но это должно произойти. Это потому, что в этом сценарии участвует другой участник - банк.
Или, может быть, когда Фред получит возмещение за свою микроволновую печь, микроволновая печь возвращается на склад, и количество запасов увеличивается. Фред, оператор кассы и контролер запаса - все это заинтересованные стороны.
В случае, когда мы добавляем что-то в журналы, есть заинтересованная сторона, которая собирается использовать эти журналы для чего-то другого. Осознание этой ценности может помочь нам понять, почему мы ведем регистрацию, и описать этот результат от имени заинтересованного лица, которое считает его ценным.
Если результаты могут быть отправлены независимо и при этом иметь ценность, они могут появляться в отдельных сценариях. Я довольно прагматичен в этом вопросе, поэтому я мог бы начать их с того же сценария, а затем рефакторизовать их позже, как только число сценариев «управления запасами» означает, что у него, вероятно, должны быть свои собственные файлы объектов.
Если результаты не могут быть отправлены независимо, как это обычно бывает с чем-либо транзакционным, мне бы хотелось, чтобы эти результаты появлялись вместе по крайней мере в одном сценарии, чтобы было очевидно, что они связанные с. Они не должны появляться в каждом сценарии. Например, после того, как мы написали сценарий, в котором у пользователя нет средств, поэтому его счет не дебетуется, нам, вероятно, больше не придется упоминать счет в случае любой другой ошибки снятия наличных. сценарии.
Эта точка зрения многих заинтересованных сторон также связана с концепцией BDD «Внешнее вовлечение», где все поведение, которое мы добавляем в систему, делается для обеспечения ценности для некоторого заинтересованного лица через некоторый интерфейс.
А как насчет взаимодействия с другими пользователями или со временем?
Иногда - очень редко - нам нужно более одного , когда , чтобы описать, что происходит, и пример увеличения счетчика входа - отличный пример для использования.
Значение счетчика входа в систему составляет только , что отключает учетную запись после 3 попыток (например).Само по себе оно не имеет значения.Это деталь реализации.Если бы мы превратили это в результат сценария, мы бы связали себя с этой реализацией, что было бы не очень хорошо.Поэтому наличие двух сценариев - одного для описания работы счетчика входа в систему и другого для демонстрации его ценности - не выглядит правильным, поскольку один из них не описывает ценное поведение:
Given Clarence logged in successfully last time
When Clarence enters his password incorrectly
Then the login counter should be incremented.
Given Clarence's login counter was incremented twice
When Clarence enters his password incorrectly
Then his account should be disabled.
Юк.Давайте не будем этого делать.
Единственное значение в этом счетчике - это взаимодействие поведения Кларенса с будущим (или прошлым) поведением Кларенса.Таким образом, у нас может быть что-то вроде:
Given Clarence logged in successfully last time
When he enters his password incorrectly
And enters his password incorrectly
And enters his password incorrectly
Then his account should be disabled.
Конечно, это немного глоток, поэтому мы, вероятно, просто скажем:
Given Clarence logged in successfully last time
When he enters his password incorrectly 3 times
Then his account should be disabled.
Мы можем сделать это, потому что этото же самое происходитНекоторые взаимодействия, однако, включают в себя разные вещи («прохождение времени» - другое, с которым я часто сталкиваюсь).
Given Clare is editing trade 12345
When Stephen edits and saves that trade
And Clare tries to save that trade
Then she should be told that Stephen has already edited it.
В этом случае, конечно, взаимодействие Клэр отличается от взаимодействия Стивена, так как ее попытка спасти не удалась.
Обратите внимание на использование попытки здесь для обозначения сбоя;Еще один пример того, как я использую предположения.Если он не говорит пытается , мы можем предположить, что событие прошло успешно.Альтернативой может быть:
When Clare saves the trade successfully
Если успешный результат не является чем-то неожиданным и ненормальным, это будет немного повторяться, поэтому я предпочитаю ничего не использовать по умолчанию, а пытается за неудачу.Разница между ними важна с точки зрения автоматизации, поскольку она позволяет нам перемещать автоматизированный рабочий процесс на страницу с ошибкой вместо страницы подтверждения.Именно поэтому мы все равно пытаемся использовать эти инструменты на английском языке.