TDD для метода средней сложности - PullRequest
2 голосов
/ 09 марта 2009

Я давно не общался с TDD и очень ржавый. Буду признателен за некоторые предложения о том, как TDD метод, описанный ниже.

Метод должен найти файл web.config в пользовательском каталоге приложения. Затем он должен извлечь и вернуть строку подключения из этого файла конфигурации.

Возвращает ноль, если по какой-либо причине строка подключения не найдена, будь то неверный путь, нет web.config или нет строки подключения в web.config.

Сначала я хочу написать тест с настройкой, которая создает каталог и записывает файл web.config со строкой соединения. Затем тест вызовет мой метод с созданным путем и вернет ненулевое значение обратно, и мой первоначальный тестовый запуск завершится неудачно, потому что мой метод-заглушка всегда возвращает нулевое значение.

Затем реализуйте метод и запустите тест, ожидая прохода. Затем в качестве предварительного теста (я забыл термин) удалите созданный каталог и вызовите метод, ожидающий нулевое значение.

Ответы [ 4 ]

4 голосов
/ 09 марта 2009

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

Во-вторых, если вы не зависите от неудачной компиляции, являющейся вашим первым неудачным тестом, то напишите первую попытку метода, чтобы вызвать исключение NotImplementedException. Это небольшой шаг, но когда вы напишите свой первый тест, по крайней мере, он потерпит неудачу. Конечно, первый тест в пустом потоке будет ожидать, что он вернет ноль, и первый код, который вы напишите, будет return null, но это нормально. Ваш следующий тест заставит вас изменить его. Продолжайте оттуда, пока не получите законченные методы.

3 голосов
/ 09 марта 2009

Похоже, у вас есть несколько TestCases с несколькими различными приборами настройки.

  1. FoundDirectory TestCase. SetUp создает ожидаемый, действительный файл.

    Может иметь несколько подклассов.

    1. Строка подключения не найдена TestCase. SetUp создает ожидаемый, но неверный файл.

    2. Плохой путь TestCase. SetUp создает ожидаемый, но неверный файл.

    3. Нет web.config TestCase. SetUp создает ожидаемый, но неверный файл.

    4. Нет строки подключения в web.config TestCase. SetUp создает ожидаемый, но неверный файл.

  2. DidntFindDirectory TestCase. SetUp гарантирует, что каталог не существует.

  3. Тестовый случай DidntFindFile. SetUp создает каталог, но не файл.

0 голосов
/ 09 марта 2009

Я полагаю, что история в вашем вопросе смешивает несколько вопросов:

  1. поиск и открытие файла,
  2. загрузка данных в «конфигурацию» (как показано)
  3. пытается получить определенный параметр из "конфигурации"

Точка 3 теперь зависит от поведения Конфигурации и может быть разработана в стиле TDD.

Точка 2 теперь зависит от того, как создается Конфигурация (например, с помощью ConfigurationLoader), и может разрабатываться способом TDD (например, для StringReader).

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

0 голосов
/ 09 марта 2009

Сделайте объект, который содержит ваш метод (или сам метод), зависимым от некоторого IConfigLoader, который вы могли бы смоделировать:

public interface IConfigLoader
{
    XmlReader LoadAppConfigFrom(string path);
}   

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...