Я понимаю, что это несколько субъективно, но я не могу найти хорошее обоснование для одного или другого:
это "должно что-то делать"
это "что-то делать "
Сторонники стиля следует упомянуть, что он заставляет вас задаться вопросом, чего вы пытаетесь достичь, в то время как хулители считают это просто излишним.
Есть ли консенсус по этому вопросу или это просто вопрос стиля?
Ответы:
Добро пожаловать на юридический английский.
Использование «следует» == «должен» == договорное обязательство. Это законничество. Это не приводит к «допросу». Это отмечает предложение как формальное договорное обязательство.
Использование «бы» == «будет» == хорошая идея. Это помечает предложение как дополнительную функцию.
Опрос является частью фасилитации, организации, помощи, укрепления доверия. Не следствие выбора слова.
Использование пустого глагола без модификатора делает предложение немного сложнее выделить как формальное требование. И в случае сверхсложных глаголов, это может быть немного рискованно, чтобы выяснить, как спрягать это.
Легко - глаголы типа «уведомить» или «создать».
Система уведомляет по электронной почте. (Глагол «уведомлять» сопряжен, «уведомляет» для «системы» - что бы это ни было.)
Система должна уведомить об этом по электронной почте. («уведомлять» становится «уведомлять» - нет спряжения. Очень просто.)
Сложные - глагольные фразы, такие как «войти в систему» или специфичные для домена глагольные фразы, такие как «извлекать, очищать, преобразовывать, дедуплицировать и загружать», или существительное типа «перспектива», которое было названо глаголом. Более длинную фразу, в которой похоронено несколько глаголов, трудно спрягать: спрягать каждый глагол? Или попытаться соединить длинную фразу, как если бы это было одно слово? Поскольку любое существительное может быть переведено в английский как глагол, трудно понять, как спрягать эти выдуманные глаголы.
Система извлекает, очищает, трансформирует, дедуплицирует и загружает, когда пользователь нажимает кнопку ввода. (Английский тривиально глаголы любой существительной фразы.) Или это извлекает, очищает, преобразовывает, дедуплицирует и загружает?
Система должна извлекать, очищать, преобразовывать, дедуплицировать и загружать, когда пользователь нажимает кнопку ввода. (Эта отвратительная фраза осталась нетронутой, нет никаких загадок относительно спряжения глаголов.)
["Какая?" Вы говорите: «Любое существительное может быть в глаголе по-английски?». Да. Любое существительное. Я собираюсь об этом сказать. Я часто об этом говорил. Даже спецификации должны быть обставлены.]
Чисто дело стилистических предпочтений. Это сводится к вопросу, предпочитаете ли вы / ваши клиенты думать о системе в настоящем или будущем времени?
Квалификаторы типа «должен» или «воля» подразумевают будущее время, но оно мягкое и читается достаточно хорошо, когда мы думаем в настоящем времени. Отсутствие квалификатора определенно указывает на настоящее время (то есть прямо в этот момент).
Я предпочитаю использовать квалификатор, потому что он хорошо читается в обоих случаях, тогда как отсутствие спецификатора читает немного странно во время разработки, когда все в будущем.
В любом случае, если вы решите использовать классификатор, я настоятельно рекомендую использовать «должен» вместо «должен» . «Должен» может быть истолкован как необязательный (несмотря на утверждение С.Лотта об обратном), но «должен» полностью устраняет любую двусмысленность - явно должен означать «не обязательно».
И потому что я пока не могу комментировать (ограничения кармы), это ответ С. Лотту о «Должен / Должен против» / «Будет / будет»: есть много двусмысленностей в отношении воли и воли, даже в написании юридического контракта. Смотрите эту статью для объяснения .
Я за использование третьего лица, настоящее время без уточнения.
Мой главный аргумент таков: тест - это история.
История состоит из сцен. Каждая сцена описывает:
Пример:
ОПИСАТЬ :
getReceiptфункцияКОНТЕКСТ : квитанция существует
IT : возвращает квитанцию
Как хороший рассказ, хороший тест легко читать.
История рассказывает вам, что делает программа, например,
С другой стороны, использование квалификатора (не имеет значения, является ли он «должен» или «должен») превращает тест в список утверждений, например:
Непрерывной истории нет: ваш ум оценивает список утверждений.
Это субъективно, но читать естественный язык (историю) проще, чем читать список утверждений.
На мой взгляд, вы всегда должны использовать «должен».
Рассуждение - с BDD, когда вы пишете тест, программное обеспечение не все же делать то , что вы хотите, чтобы это сделать, так сказав , что это «что - то делает» ложно. Он «должен что-то делать», и тесты будут проходить, пока он продолжает что-то делать.
Из behaviour-driven.org под названием "GettingTheWordsRight" :
Короче говоря, слова, которые мы используем для описания вещей, влияют на то, как мы (и другие) думаем об этих вещах. Это не просто вопрос мелочности в семантике, поскольку определенные слова несут в себе нюансы, которые влияют на то, как мы интерпретируем значение фразы как на интеллектуальном, так и на эмоциональном уровне. Наш язык изобилует описательными словами и фразами, поэтому разумно использовать слова, которые четко передают смысл элементов, которые мы хотим описать в коде.
В случае BDD лично я почти всегда использую слово « должен» при именовании тестов, поскольку его использование подразумевает, что, хотя тест предназначен для получения определенного результата, могут возникнуть другие неожиданные последствия , которые необходимо будет устранить с, если результат теста считается действительным. Возможно, вы могли бы использовать слова ожидать или должныаналогично, однако, эти слова подразумевают более императивную точку зрения, так что название теста может быть ошибочно означать «нет ничего плохого в тесте, предположим, что реализация испорчена», тогда как * следует «подразумевает, что тест может будьте верны, но, возможно, потребуется еще раз проверить на наличие ошибок, если результаты теста, кажется, не суммируются. Мне это нравится, потому что это влияет на ваше мышление, так что вам предлагается сохранять непредвзятость при написании кода, что очень важно, если вы хотите избежать застревания при попытке отладки кода и обнаружите, что ищите ошибки в неправильном месте из-за предположения.
Однако я видел, что почти «религиозное» применение этого слова должно потерпеть неудачу, когда оно применяется в качестве префикса для имен тестов, так как оно вынуждает участвующих программистов проходить определенную умственную и лингвистическую гимнастику, чтобы предоставить название теста, которое было значимым, и в таких случаях это означало, что намерение получить правильные слова не соответствует его ожиданиям, и в результате сами тесты становятся трудными для расшифровки. Когда такая ситуация выплывает, я обычно использую слово должнов любом месте имени метода тестирования, чтобы имя передавало его метод просто и ясно. Однако я бы не стал применять конкретное слово, если бы другие слова были одинаково подходящими в данном контексте. Однако хитрость заключается в том, чтобы выбрать слова, которые не оставляют места для споров о том, что что-то представляет в коде, и которые заставляют вас задуматься о том, что должен делать ваш код, не полагаясь на простое следствие.