Как описать ожидаемые сообщения об ошибках в BDD / огурчик - PullRequest
1 голос
/ 07 февраля 2020

Мы только начинаем с BDD в нашей компании, и в настоящее время мы пытаемся написать наши первые функции. Мы создали что-то вроде следующего:

Feature: There can only be one
It is important that there is only one Highlander in the system for a given time period.

Scenario: Inserting a new Higlander for a time period already taken by another 
Given there is a Highlander Adam in the system for time period 1820-1900
When I insert a Higlander Bert for time period 1800-1900
Then the System raises Error Code "ONLY1"  

Scenario: Inserting a new Higlander for a free time period
Given there is a Highlander Adam in the system for time period 1820-1900
When I insert a Higlander Bert for time period 1901 - 1902
Then the System raises no Error

Мой вопрос касается кода ошибки (ONLY1) в первом сценарии. В настоящее время наша система вызывает много ошибок, но у нас нет простого способа определить конкретное c условие ошибки. Нашей Системе более 15 лет. Разве не смешно, что мы не находили это проблемой на протяжении стольких лет? Я нахожу замечательно, что BDD делает это настолько очевидным, что нам нужен четкий общий язык для идентификации наших сообщений об ошибках.

Некоторые из моих коллег утверждают, что код ошибки не требуется. Это означает, что мы должны написать утверждение следующим образом:

Then the System shows the error "There can only be 1 Highlander for a given time period."

Это заставляет меня съеживаться, потому что

  • Тест сломается, если мы позже решим изменить текст на что-то иначе
  • Тест будет успешным только на английском языке sh версия программного обеспечения (мы поддерживаем несколько языков)
  • Код ошибки отлично подходит для поиска информации в базе знаний или в Suppoert tickets.

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

Как вы проверяете ошибки? Вы используете коды или исключения или просто текст?

С наилучшими пожеланиями Мат

1 Ответ

2 голосов
/ 12 февраля 2020

Строго говоря, с точки зрения BDD, вы хотите сосредоточиться на ожидаемом поведении . Держите ваши тесты без технических деталей. При этом коды ошибок являются техническими деталями. При попытке придерживаться BDD избегайте кодов ошибок в ваших файлах функций. Вместо этого поместите коды ошибок в определения шагов.

Хотя сообщения об ошибках, удобные для пользователя, немного отличаются. Сообщение об ошибке, отображаемое конечному пользователю, не является технической деталью в том же смысле, что и код ошибки или перечисление. Это то, что конечный пользователь должен понимать. Если они не понимают удобного сообщения об ошибке, оно не является удобным и должно быть переписано до тех пор, пока оно не будет. Таким образом, приведенный ниже пример совершенно верен BDD:

Then the System shows the error "There can only be 1 Highlander for a given time period."

Вы также должны понимать недостаток этого подхода. Любое изменение в терминологии сообщения означает, что вам необходимо обновить все тесты, которые ссылаются на это сообщение. Хотя размещение сообщения в ваших функциях может не нарушать BDD, оно делает ваш набор тестов более трудоемким в обслуживании. Лучшее утверждение отражает суть поведения, не требуя, чтобы автор сценария знал точные детали пользовательского интерфейса:

Then the system says there can only be 1 highlander

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

Проверьте BDD 101: Написание хорошего огурца для получения хороших указаний.

...