2010-07-02 6 views
2

Мне нужно создать единичный тест для метода, который возвращает xmldocument. Что я должен проверять в таком случае? Метод проверяет базу данных и создает xmldocument и отправляет данные клиенту.Единичные тесты для возврата метода xmldocument

Должен ли я выглядеть, если возвращаемый xmldocument имеет все ожидаемые теги xml? или я должен иметь файл Expected.xml и соответствовать xmldocument, возвращенному этим xml-файлом. Если я перехожу к второму подходу, то то, что я ищу, отсутствует в базе данных, тогда этот тест всегда терпит неудачу. Я хочу написать тест, который не зависит от каких-либо конкретных данных, но должен проверить, правильны ли данные, возвращаемые методом, или нет, поэтому я склоняюсь к подходу к проверке только тегов и полагаю, что если есть теги и значения в этих тегах также верны.

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

<Member id=""> 
<Book> 
    <Name>Book_name</Name> 
    <Author>author</Author> 
    <Due_date>due date </Due_Data> 
</Book> 
</Member> 

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

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

Спасибо,

ответ

2

Проблема заключается не столько в XmlDocument - это легко проверить, соответствует ли это ожидаемому результату.

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

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

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

редактировать

Чтобы ответить на ваши изменения, вы можете проверить, если определенные биты в XmlDocument являются «действительными» довольно легко. например Является ли корневой элемент «Член»:

Assert(doc.DocumentElement.Name == "Member"); 

ли дочерний элемент «Имя», которое не пустым, и не имеет детей корневой элемент?

Assert(doc.DocumentElement["Name"] != null); 
Assert(!string.IsNullOrEmpty(doc.DocumentElement["Name"].InnerText)); 
Assert(doc.DocumentElement["Name"].ChildNodes.Count == 0); 

и т.д.

+0

Да, Mockdatabase, кажется, правильный путь. благодаря –

0

Будет ли результирующий документ всегда пчелиных 100% идентичны, или же вы должны фактически проверить данные внутри сам документ?

Если 100%, я бы сохранил копию файла ожидаемого документа в тестовом проекте, добавил его в файл ресурсов и выполнил строку с прямыми < -> сравнение строк.

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

100% -ная версия проще и точнее, если она применима к вашему сценарию.

Смежные вопросы