единичный тест для экспорта XML-метода

Question

У меня есть метод ExportXMLFiles(string path) для экспорта xml-файлов по определенному пути с некоторыми элементами внутри него, такими как FirstName, LastName, MajorSubject. Эти значения выбираются из базы данных.

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

Есть ли другой способ для этого?

Answer 1

Вы абсолютно не хотите использовать фактическую базу данных в своем модульном тесте. Он добавляет один уровень сложности, с которым вы не хотите иметь дело в своих модульных тестах. Это также делает ваши юнит-тесты менее надежными и медленными. Посмотрите, можете ли вы разбить функциональность базы данных на интерфейс, который вы можете создать, используя фальшивую структуру. Попробуйте найти что-то вроде moq или, если этого недостаточно, зарегистрируйтесь moles от Microsoft.

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

Answer 2

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

Единичный тест рассматривает ОДИН элемент функциональности и не полагается на поведение чего-либо еще.

Так что посмотрите на использование шаблона, такого как инъекция зависимостей, чтобы вы могли обеспечить (т.е. вводить) базы данных и зависимости файловой системы. Посмотрите на насмешливую структуру, такую ​​как NMock, или напишите ваши собственные легкие поддельные объекты, которые реализуют тот же интерфейс, что и зависимости, и затем вы можете передать их в тестируемые вами функции.

Answer 3

Что несет ответственность за этот метод? Является ли это дампом данных в виде XML-файлов по определенному пути? Если да, то вам нужно будет проверить, действительно ли файлы созданы.

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

// setup mock data source to supply canned data 
// call myObject.ExportToXml(mockDataSource, tempPath) 
// verify files are created in tempPath 

Наконец, этот класс должен реализовать роль (DataExporter), так что тесты, которые используют DataExporter быстро/не должны иметь дело с файловыми системами (или XML).