При написании спецификаций в стиле BDD вы должны использовать «должен» или нет? [закрыто]

12

Я понимаю, что это несколько субъективно, но я не могу найти хорошее обоснование для одного или другого:

это "должно что-то делать"
это "что-то делать "

Сторонники стиля следует упомянуть, что он заставляет вас задаться вопросом, чего вы пытаетесь достичь, в то время как хулители считают это просто излишним.

Есть ли консенсус по этому вопросу или это просто вопрос стиля?

жюльен
источник

Ответы:

3

Добро пожаловать на юридический английский.

Использование «следует» == «должен» == договорное обязательство. Это законничество. Это не приводит к «допросу». Это отмечает предложение как формальное договорное обязательство.

Использование «бы» == «будет» == хорошая идея. Это помечает предложение как дополнительную функцию.

Опрос является частью фасилитации, организации, помощи, укрепления доверия. Не следствие выбора слова.

Использование пустого глагола без модификатора делает предложение немного сложнее выделить как формальное требование. И в случае сверхсложных глаголов, это может быть немного рискованно, чтобы выяснить, как спрягать это.

Легко - глаголы типа «уведомить» или «создать».

  • Система уведомляет по электронной почте. (Глагол «уведомлять» сопряжен, «уведомляет» для «системы» - что бы это ни было.)

  • Система должна уведомить об этом по электронной почте. («уведомлять» становится «уведомлять» - нет спряжения. Очень просто.)

Сложные - глагольные фразы, такие как «войти в систему» ​​или специфичные для домена глагольные фразы, такие как «извлекать, очищать, преобразовывать, дедуплицировать и загружать», или существительное типа «перспектива», которое было названо глаголом. Более длинную фразу, в которой похоронено несколько глаголов, трудно спрягать: спрягать каждый глагол? Или попытаться соединить длинную фразу, как если бы это было одно слово? Поскольку любое существительное может быть переведено в английский как глагол, трудно понять, как спрягать эти выдуманные глаголы.

  • Система извлекает, очищает, трансформирует, дедуплицирует и загружает, когда пользователь нажимает кнопку ввода. (Английский тривиально глаголы любой существительной фразы.) Или это извлекает, очищает, преобразовывает, дедуплицирует и загружает?

  • Система должна извлекать, очищать, преобразовывать, дедуплицировать и загружать, когда пользователь нажимает кнопку ввода. (Эта отвратительная фраза осталась нетронутой, нет никаких загадок относительно спряжения глаголов.)

["Какая?" Вы говорите: «Любое существительное может быть в глаголе по-английски?». Да. Любое существительное. Я собираюсь об этом сказать. Я часто об этом говорил. Даже спецификации должны быть обставлены.]

С. Лотт
источник
5
Вы говорите, что использование «следует» не приводит к «допросу»; Мой опыт показывает, что это так, особенно с людьми, плохо знакомыми с тестированием / TDD. Это также имеет эффект дифференциации результатов от контекста и событий. «И заказ поступает на склад» не говорит мне, заставляю ли я заказ поступить нажатием кнопки или это должно произойти автоматически, тогда как «И заказ должен поступить на склад» говорит мне, что это это то, что я должен проверить. BDD - это разговорный, не юридический, английский (или естественный язык по выбору).
Лунивор
3
Я ценю, что у вас есть другой язык там. BDD началась в Лондоне, хотя ... со словом "следует";) ОП спросила, был ли консенсус по этому вопросу, и с 2004 года -> dannorth.net/introduction-bdd
Lunivore
1
Это идея, что вы используете «должен» законным, не задавая вопросов способом, который я не нахожу полезным. Вид противоположности преднамеренному мышлению открытия, с которого началось BDD. Я провожу свою жизнь, пытаясь помочь людям, которые начали с «спецификации», а затем чувствуют, что они не могут подвергнуть это сомнению
Лунивор
1
Если бы вы отредактировали свой ответ так, чтобы в него входило что-то вроде «Некоторым людям нравится« должен », потому что это приводит к допросу», а не к тому, что говорится в настоящее время, а именно «это не приводит к допросу», я был бы очень счастливый. Опрашивающий аспект BDD является для меня одним из наиболее важных, и то, как вы это сформулировали, устраняет этот аспект, а не предоставляет дополнительный контекст. Спасибо за этот разговор, независимо от того, редактируете ли вы ответ или нет; Я действительно ценю уважительный диалог.
Лунивор
11
Стандарт IETF для написания РЛКА конкретно говорится , что «MUST» и «ДОЛЖЕН» является «REQUIRED», «должен» является «РЕКОМЕНДУЕТСЯ» и «МАЙ» есть «ДОПОЛНИТЕЛЬНО».
oosterwal
4

Чисто дело стилистических предпочтений. Это сводится к вопросу, предпочитаете ли вы / ваши клиенты думать о системе в настоящем или будущем времени?

Квалификаторы типа «должен» или «воля» подразумевают будущее время, но оно мягкое и читается достаточно хорошо, когда мы думаем в настоящем времени. Отсутствие квалификатора определенно указывает на настоящее время (то есть прямо в этот момент).

Я предпочитаю использовать квалификатор, потому что он хорошо читается в обоих случаях, тогда как отсутствие спецификатора читает немного странно во время разработки, когда все в будущем.

В любом случае, если вы решите использовать классификатор, я настоятельно рекомендую использовать «должен» вместо «должен» . «Должен» может быть истолкован как необязательный (несмотря на утверждение С.Лотта об обратном), но «должен» полностью устраняет любую двусмысленность - явно должен означать «не обязательно».


И потому что я пока не могу комментировать (ограничения кармы), это ответ С. Лотту о «Должен / Должен против» / «Будет / будет»: есть много двусмысленностей в отношении воли и воли, даже в написании юридического контракта. Смотрите эту статью для объяснения .

Кертис Батт
источник
«Отсутствие квалификатора выглядит немного странно во время разработки, когда все в будущем» - хорошо, если вы делаете TDD и написали тест, но еще не написали код, ваш тест сейчас не пройден. Хотя семантика «она должна пройти в будущем» будет означать, что она может пройти СЕЙЧАС. Таким образом, настоящее время приносит больше ясности, по крайней мере, в случае с TDD: это не обещание о будущем, которое терпит неудачу, а ожидаемое поведение СЕЙЧАС, которое не выполняется.
Михаил Васин
2

Я за использование третьего лица, настоящее время без уточнения.

Мой главный аргумент таков: тест - это история.

История состоит из сцен. Каждая сцена описывает:

  • предмет
  • контекст
  • действие

Пример:

ОПИСАТЬ : getReceiptфункция

КОНТЕКСТ : квитанция существует

IT : возвращает квитанцию

Как хороший рассказ, хороший тест легко читать.

История рассказывает вам, что делает программа, например,

  • начинает транзакцию
  • делает запрос
  • нормализует ответ
  • завершает сделку
  • возвращает квитанцию

С другой стороны, использование квалификатора (не имеет значения, является ли он «должен» или «должен») превращает тест в список утверждений, например:

  • должен начать транзакцию
  • должен сделать запрос
  • должен нормализовать ответ
  • должен завершить сделку
  • должен вернуть квитанцию

Непрерывной истории нет: ваш ум оценивает список утверждений.

Это субъективно, но читать естественный язык (историю) проще, чем читать список утверждений.

Gajus
источник
1

На мой взгляд, вы всегда должны использовать «должен».

Рассуждение - с BDD, когда вы пишете тест, программное обеспечение не все же делать то , что вы хотите, чтобы это сделать, так сказав , что это «что - то делает» ложно. Он «должен что-то делать», и тесты будут проходить, пока он продолжает что-то делать.

sevenseacat
источник
1
«Еще не существует», кажется, больше оснований для использования настоящего времени вместо «должен». BDD предназначен для приемочного тестирования, и если система еще ничего не делает, она должна немедленно выйти из строя. Похоже, между BDDer'ами существует разрыв в использовании «следует» или нет.
Бренден
1

Из behaviour-driven.org под названием "GettingTheWordsRight" :

Короче говоря, слова, которые мы используем для описания вещей, влияют на то, как мы (и другие) думаем об этих вещах. Это не просто вопрос мелочности в семантике, поскольку определенные слова несут в себе нюансы, которые влияют на то, как мы интерпретируем значение фразы как на интеллектуальном, так и на эмоциональном уровне. Наш язык изобилует описательными словами и фразами, поэтому разумно использовать слова, которые четко передают смысл элементов, которые мы хотим описать в коде.

В случае BDD лично я почти всегда использую слово « должен» при именовании тестов, поскольку его использование подразумевает, что, хотя тест предназначен для получения определенного результата, могут возникнуть другие неожиданные последствия , которые необходимо будет устранить с, если результат теста считается действительным. Возможно, вы могли бы использовать слова ожидать или должныаналогично, однако, эти слова подразумевают более императивную точку зрения, так что название теста может быть ошибочно означать «нет ничего плохого в тесте, предположим, что реализация испорчена», тогда как * следует «подразумевает, что тест может будьте верны, но, возможно, потребуется еще раз проверить на наличие ошибок, если результаты теста, кажется, не суммируются. Мне это нравится, потому что это влияет на ваше мышление, так что вам предлагается сохранять непредвзятость при написании кода, что очень важно, если вы хотите избежать застревания при попытке отладки кода и обнаружите, что ищите ошибки в неправильном месте из-за предположения.

Однако я видел, что почти «религиозное» применение этого слова должно потерпеть неудачу, когда оно применяется в качестве префикса для имен тестов, так как оно вынуждает участвующих программистов проходить определенную умственную и лингвистическую гимнастику, чтобы предоставить название теста, которое было значимым, и в таких случаях это означало, что намерение получить правильные слова не соответствует его ожиданиям, и в результате сами тесты становятся трудными для расшифровки. Когда такая ситуация выплывает, я обычно использую слово должнов любом месте имени метода тестирования, чтобы имя передавало его метод просто и ясно. Однако я бы не стал применять конкретное слово, если бы другие слова были одинаково подходящими в данном контексте. Однако хитрость заключается в том, чтобы выбрать слова, которые не оставляют места для споров о том, что что-то представляет в коде, и которые заставляют вас задуматься о том, что должен делать ваш код, не полагаясь на простое следствие.

S.Robins
источник