P>- shouldReturnAccountCurrentBalance
P>- shouldThrowExceptionIfAccountIdNegative
P>- shouldThrowExceptionIfAccountNotFound
P>- shouldThrowExceptionIfAccountClosed

Зачем столько шума? Трудно продираться через все эти should, when, then, given. Народ прочитал, что так правильно и теперь натягивает этот паттерн на все тестовые методы. Так намного читабельнее:

can_return_account_current_balance
throws_exception_if_account_id_is_negative
throws_exception_if_account_is_not_found
throws_exception_if_account_is_closed

Кстати, из имен тестов совершенно непонятно, _когда_ он кидает исключения. При вызове любого метода? В конструкторе? В dispose? При сериализации?

VS>Зачем столько шума? Трудно продираться через все эти should, when, then, given. Народ прочитал, что так правильно и теперь натягивает этот паттерн на все тестовые методы. Так намного читабельнее:
VS>

VS>can_return_account_current_balance
VS>throws_exception_if_account_id_is_negative
VS>throws_exception_if_account_is_not_found
VS>throws_exception_if_account_is_closed
VS>

Не проверял, но уверен, что материалы по BDD несложно найти, и среди них немало будет начинаеться именно с "зачем". Там идея шире чем просто именование тестовых методов. Вкратце — should, потому что тест задаёт _требования_ к поведению системы или компонента. given/when/then — потому что требования выражаются в _структурированных примерах_.

Бесспорно, если вам/вашей команде так трудно, а по-другому легко, то у вас есть полное право BDD не применять.

VS>Кстати, из имен тестов совершенно непонятно, _когда_ он кидает исключения. При вызове любого метода? В конструкторе? В dispose? При сериализации?

Да, поскольку тестируется не метод, а требование к компоненту, реализующему определённую функцию. Соответственно упавший тест показывает не на метод, а на требование, которое компонент не обеспечивает.

P>Не проверял, но уверен, что материалы по BDD несложно найти, и среди них немало будет начинаеться именно с "зачем". Там идея шире чем просто именование тестовых методов. Вкратце — should, потому что тест задаёт _требования_ к поведению системы или компонента. given/when/then — потому что требования выражаются в _структурированных примерах_.

P>Бесспорно, если вам/вашей команде так трудно, а по-другому легко, то у вас есть полное право BDD не применять.

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

P>Да, поскольку тестируется не метод, а требование к компоненту, реализующему определённую функцию. Соответственно упавший тест показывает не на метод, а на требование, которое компонент не обеспечивает.

Из _наименования_ тестового метода должно быть ясно, при каких условиях ожидается некое поведение. Из shouldThrowExceptionIfAccountClosed ясно только, что тестируемый компонент кидает исключение, если счет закрыт. Но вот в каком сценарии он это делает — не ясно. Может быть он висит себе в памяти и каждые 10 минут кидает исключение? Или он это делает, когда ему посылают некоторое подмножество сообщений? Чтобы это выяснить, надо смотреть код теста, что в разы увеличивает время, нужное на изучение компонента. Сгенерировать документацию по таким тестам невозможно — ценность ее будет минимальна.

Здравствуйте, Кодёнок, Вы писали:

Кё>Метод сам по себе тестировать нельзя — в любом случае будет создан экземпляр объекта.

Никто не запрещает передавать null в качестве this параметра.

VS>Из _наименования_ тестового метода должно быть ясно, при каких условиях ожидается некое поведение. Из shouldThrowExceptionIfAccountClosed ясно только, что тестируемый компонент кидает исключение, если счет закрыт. Но вот в каком сценарии он это делает — не ясно. Может быть он висит себе в памяти и каждые 10 минут кидает исключение? Или он это делает, когда ему посылают некоторое подмножество сообщений? Чтобы это выяснить, надо смотреть код теста, что в разы увеличивает время, нужное на изучение компонента. Сгенерировать документацию по таким тестам невозможно — ценность ее будет минимальна.

Если вы следуете SRP в дизайне, то запутаться будет сложно. В этом конкретном случае всё ещё проще — входные условия таковы, что во всей картине мира существует один единственный метод. Но в целом я не спорю, понятные названия для тестов важны и приветствуются.

Не могу комментировать подход с генерированием документации по тестам — не сталкивался. Могу сказать что при хорошем DSL тесты неплохо читаются в исходном виде.

Ну и пожалуй, повторюсь — если у вас есть своё видение того, как что должно быть, и оно для вас работает — пусть работает и дальше.
Если же такового нет — как у топикстартера — то вполне можно посмотреть на BDD, как продуманный, описанный, и практичный подход, продолжающий идею TDD.