TDD в проекте импорта текстовых файлов

Question

Я только начинаю, и да, я еще не написал никаких тестов (я не фундаменталист, я не люблю ошибки компиляции только потому, что нет теста), но мне интересно, где приступите к выполнению проекта, который анализирует записи плоских файлов фиксированной длины в соответствии с отображением XML в класс, представляющий расширенный набор всех макетов файлов, перед записью (с преобразованием) сведений о классе в таблицу БД.

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

Answer 1

Все дело в разложении проблемы на части. Некоторые примеры:

• Программа чтения файлов / потоков
• Картограф ввода
• Загрузчик картографирования ввода
• Формат файла
• Коллекция файлов с разметкой
• Уровень доступа к данным

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

Answer 2

Два метода, которые я нашел полезными для тестирования классов на основе ввода-вывода:

• Где возможно, говорите в общих терминах, таких как StreamReader и Stream, а не в именах файлов. Легко создать StringReader или MemoryStream в тестах и ​​предоставить данные таким образом.
• Иногда вам нужно больше данных, чем вы действительно хотите вставить в литералы в коде. В этом случае добавьте тестовые файлы (иногда как входные, так и ожидаемые выходные данные) в качестве встроенных ресурсов и используйте Assembly.GetManifestResourceStream для получения данных во время выполнения.

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

Answer 3

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

Я бы очень рекомендовал издеваться над вашими внешними зависимостями. Это сделает ваше приложение непарным, и я уверен, что в будущем его будет проще поддерживать. Кроме того, ваши тесты будут намного более управляемыми.

Существует множество Mock Frameworks , которые могут вам помочь. Я должен признать, что если вы никогда не делали этого раньше, есть некоторая кривая обучения. Но мы занимаемся разработкой программного обеспечения, и всегда есть чему поучиться.

Если вы решили потратить некоторое время на изучение тестирования с помощью mock, вы можете начать с этой статьи .

Удачи.