Подход к тестированию для XDocument.Load () и XDocument.Save ()

Question 1

Я работаю с XDocument в приложении MVC4 Web API в Visual Studio 2010 и не уверен в стратегии тестирования.

Большинство моих модульных тестов используют находящийся в памяти XDocument, который хорошо работает для тестов контроллеров, служб и репозиториев.

Однако у меня есть сценарии XDocument.Load(filename) и XDocument.Save (filename), которые я хотел бы протестировать (с помощью модульных или интеграционных тестов).

Я смотрел следующий вопрос \ ответ на SO здесь, но я не знаю, что делать дальше.

public class PathProvider
{
   public virtual string GetPath()
   {
      return HttpContext.Current.Server.MapPath("App_Data/policies.xml")
   }
}

PathProvider pathProvider = new PathProvider();
XDocument xdoc = XDocument.Load(pathProvider.GetPath());

Итак, я понимаю, что теперь могу имитировать вызовы любых вызовов XDocument.Load (pathProvider.GetPath ()).

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

Благодарность

Дэви

testing mocking tdd linq-to-xml

5

davy 14 Фев 2013 в 15:51

Вы можете имитировать звонки на XDocument.Load, используя MS Fakes.

–

Daniel Hilgarth

14 Фев 2013 в 15:57

Спасибо, я должен был сказать, что использую VS 2010 и не могу выполнить обновление. Я считаю, что фейки в 2010 году не работают.

–

davy

14 Фев 2013 в 19:07

Вы можете использовать предшественника Moles

–

Daniel Hilgarth

14 Фев 2013 в 19:10

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

–

davy

14 Фев 2013 в 19:14

«Однако у меня есть сценарии XDocument.Load (имя файла) и XDocument.Save (имя файла), которые я хотел бы протестировать (с помощью модульных или интеграционных тестов)». Что бы вы хотели протестировать? Фактическая структура XML (интеграционный тест) или тот факт, что вызывается метод Save или Load (модульный тест)? И правильно ли я понимаю, что вы работаете с XDocument в своем программном обеспечении, и вам нужно иметь дело только со ссылками на файлы в выделенном классе?

–

bas

14 Фев 2013 в 20:29

Answer

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

Мой ответ - нет, по крайней мере, не с автоматизированного теста.

Просто из-за предоставленного вами фрагмента кода PathProvider является оболочкой (адаптером) вокруг платформы ASP.NET. Единственными тестами, на которые я бы здесь полагался, были бы тесты совместной работы, например Я бы проверил, что GetPath () вызывается тогда, когда вы этого ожидаете. При этом ключевым моментом здесь является контекст.

PathProvider pathProvider = new PathProvider();
XDocument xdoc = XDocument.Load(pathProvider.GetPath());

Приведенный выше код пахнет «тестированием фреймворка», поэтому я бы даже не стал проводить модульное тестирование такого кода. Если вы действительно хотите убедиться, что эта часть кода правильно работает с XML-файлами и т. Д., Я бы вернулся к интеграционному тесту. Хотя учтите, что это может быть медленным и хрупким.

Поэтому моим решением было бы абстрагироваться от концепции загружаемого XML-документа, как у вас с PathProvider. Отсюда будет достаточно ручного тестирования. Попутно, если в такие адаптеры включена какая-либо логика домена, я бы извлек классы / методы, которые вы могли бы тестировать изолированно, не беспокоясь о XML или загрузке документов и т. Д.

2

Finglas 16 Фев 2013 в 17:27

Question 2

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

Мой ответ - нет, по крайней мере, не с автоматизированного теста.

Просто из-за предоставленного вами фрагмента кода PathProvider является оболочкой (адаптером) вокруг платформы ASP.NET. Единственными тестами, на которые я бы здесь полагался, были бы тесты совместной работы, например Я бы проверил, что GetPath () вызывается тогда, когда вы этого ожидаете. При этом ключевым моментом здесь является контекст.

PathProvider pathProvider = new PathProvider();
XDocument xdoc = XDocument.Load(pathProvider.GetPath());

Приведенный выше код пахнет «тестированием фреймворка», поэтому я бы даже не стал проводить модульное тестирование такого кода. Если вы действительно хотите убедиться, что эта часть кода правильно работает с XML-файлами и т. Д., Я бы вернулся к интеграционному тесту. Хотя учтите, что это может быть медленным и хрупким.

Поэтому моим решением было бы абстрагироваться от концепции загружаемого XML-документа, как у вас с PathProvider. Отсюда будет достаточно ручного тестирования. Попутно, если в такие адаптеры включена какая-либо логика домена, я бы извлек классы / методы, которые вы могли бы тестировать изолированно, не беспокоясь о XML или загрузке документов и т. Д.

2

Finglas 16 Фев 2013 в 17:27

Подход к тестированию для XDocument.Load () и XDocument.Save ()

1 ответ

Похожие вопросы

Связанные вопросы

Новые вопросы

testing