Как мне реализовать этот шаг спецпотока?

Question

Хорошо, я решил попытаться справиться со всем процессом TDD от начала до конца.

Я пишу простой блог в ASP.NET MVC 2 Application и начал с приемочных тестов, чтобы проверить свои возможности по мере их реализации. Я использую SpecFlow в качестве моего BDD / ATDD фреймворка.

Я читал « Растущие объектно-ориентированные системы, управляемые тестами », поэтому я начал так, как я.

Я был бы в точке, описанной как нулевая итерация в книге, где я создаю "Ходячий скелет"

Я решил начать процесс входа в систему как мой «самый тонкий функционал, который тестирует все компоненты системы». В данном случае сам сайт и база данных.

Итак, я написал историю, подробно описывающую вход в систему, и первый сценарий, который я пишу, - вход в систему успешно.

Одна из данностей в указанном сценарии -

"Given there is a registered user with the username 'TestUser' and password 'TestPassword'"

Однако я не уверен, как бы я реализовал этот шаг.

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

Я думал о написании какого-то класса DatabaseHelper, который может вставить его для меня. Однако он будет содержать хеш-код для хеширования пароля, и тогда самому приложению потребуется тот же хеш-код, который, похоже, нарушает DRY.

Так что на самом деле здесь есть несколько связанных вопросов:

• Означает ли тот факт, что я борюсь с этим шагом, я должен начать откуда-то еще? Хотя система входа в систему довольно важна для остальной части сайта? Возможно, это не самый тонкий функционал, который тестирует и сайт, и базу данных?
• Если бы вы начали с того же места, что и я, как бы вы это сделали? Вы не будете беспокоиться о СУХОЙ еще? Поскольку Acceptance Tests тестирует функциональность извне через браузер, возможно, я мало что могу сделать?

Я должен извиниться, если вопрос кажется несколько расплывчатым, у меня нет никого, кто мог бы изучить TDD с этой стороны, и это один из тех сдвигов парадигмы, что у меня просто еще не было такого момента "а-ха". 1032 *

Заранее спасибо.

Answer 1

Если вы выполняете BDD, могу ли я предложить начать не с самого тонкого среза, который тестирует все компоненты, а с самого тонкого среза, который тестирует наиболее рискованный компонент?

Предположим, что любой пользователь, имеющий доступ к системе, уже вошел в систему. Вход в систему не совсем рискован. Это было сделано 15 000 раз.

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

Определите, какие биты системы вам известны меньше всего. Создайте сценарии и поговорите об этих элементах системы. Вам не нужно расширять систему с самого начала - вы можете выбрать любую точку, которая вам нравится! Какие части системы делают вас наиболее неудобными? Какие биты делают ваши заинтересованные стороны наиболее неудобными?

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

Answer 2

Было бы проще начать со сценария, когда такого зарегистрированного пользователя нет?Система тоже должна это обрабатывать, и то, что она делает, может быть написано без чего-либо, кроме заглушки, которая говорит «нет такого пользователя» для базы данных.