2009-08-11 2 views
1

Название, вероятно, не очень понятно. У меня есть следующий пример:как сформулировать результат действия в BDD/TDD

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

Как я могу это выразить в тесте? 'TestShouldReturnAuthObjectWithStatusSuccessOnValidLogin'?

ответ

5

testValidLoginIsSuccessful или testIsSuccessfulOnValidLogin кажется достаточно хорошо для меня.

Для тестирования ошибок, вы можете использовать что-то вроде testGetsCustomMessageOnUserNotFound

Вы должны избегать деталей реализации во имя метода.

+0

Давайте скажем, этот Authenticator использует некоторые другие классы с определенными обязанностями для выполнения некоторой работы (например, подключение к базе данных). Если я пишу тесты для этих классов, значит ли это, что я передаю детали реализации пакета «полная аутентификация»? – koen

+0

Нет, я просто говорю об имени метода. И вам, вероятно, следует издеваться над этими другими классами, если вы хотите его протестировать. Затем вы тестируете эти другие классы изолированно и видите, работают ли они изолированно. –

+0

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

2

Не видя, как эти тесты реализованы, кажется, что из-за того, что наблюдения перегружены.

Если этот тест не удался, вам нужно будет сделать рытье, чтобы узнать, было ли это потому, что (a) объект AuthResult не был возвращен, или (b) статус не был «успешен», и, кроме того, не было никакого AuthResult потому что аутентификатор никогда не подключался к базе данных или не выполнял другие требуемые действия?

Я бы назвал прибор When_told_to_authenticate_with_valid_credentials, а затем отделить утверждения в двух различных наблюдений:
1. should_return_an_AuthResult
2. should_be_successful

Если вы дразнить из этих других классов Самуил справедливо предположил, вы можете дополнительно предусматривается, что Authenticator ведет себя, как вы ожидаете:
3. should_connect_to_the_database
4. и т.д.

+0

Не стоит_return_an_AuthРезультаты реализации? – koen

+0

Да, это деталь реализации. Я не согласен с предпосылкой, что детали реализации не должны включаться в имена методов TEST, потому что (1) это именно реализация, с которой вы работаете, и тестируете, когда фокусируетесь на поведении (а не на состоянии), (2) поэтому имя метода должно четко отражать то, что передается или не удается, и (3) тестовые сборки не публикуются и не развертываются. – Jay

+0

Я не согласен с точкой 1. Если мой тест подтверждает, что мой метод работает правильно, мне все равно, что такое реализация. И если мой тест делает предположения о реализации, то я могу сломать тесты, если позже решу реорганизовать реализацию. – JeffH