Строго говоря, с точки зрения 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: Написание хорошего огурца для получения хороших указаний.