Разработка через тестирование для ASP.NET MVC 3 - анализ исходного файла XML - PullRequest
1 голос
/ 18 августа 2011

Привет хотел бы обратиться к сообществу, чтобы получить понимание и советы на подходе к разработке через тестирование для работы, которую я выполняю.

Я работаю над проектом ASP.NET MVC3, который анализирует физический файл XML (содержащий данные диаграмм и таблиц). Сначала приложение генерирует модельное представление узлов xml. Контроллер предназначен для реализации логики приложения,
который в конечном итоге отображает определенный HTML-вид с помощью диаграмм и таблиц.

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

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

Первый тест, который я хочу сделать (я думаю), это загрузить xml и проверить правильность end_Date

У меня есть класс XMLHelper, который загружает xml и возвращает представление класса заголовка с датой окончания свойства.

Так что мой конкретный код будет выглядеть примерно как

var dataset = XmlHelper.Load(filePathOrXmlStream);
var header=dataset.Header;

Assert.AreEqual("5/06/2011",header.EndDate);

предполагает, что приведенный ниже XML используется для загрузки потока или файла.

Источник XML

<dataset>
  <header>
    <end_date>5/06/2011</end_date>
    <dimension id="mkt" desc="market">
      <item mkt="0" desc="Company A" />
      <item mkt="1" desc="Company B" />
    </dimension>
    <dimension id="prd" desc="product">
      <item prd="0" desc="Product A " Groups_Total="Segment Totals" Total="Yes" Product="All" grp="Category" />
    </dimension>
    <dimension id="msr" desc="measure">
      <item msr="0" tag="ACTIVE_1" desc="Active Products" />
    </dimension>
    <dimension id="tim" desc="time">
      <item tim="0" tag="LAST WEEK -52" desc="06/06/10 " />
      <item tim="1" tag="LAST WEEK -26" desc="05/12/10 " />
      <item tim="2" tag="LAST WEEK 0" desc="05/06/11 " />
    </dimension>
  </header>
  <data>
    <dpGroup tim="0">
      <dp mkt="0" prd="0" msr="0" tim="0">1031</dp>
      <dp mkt="1" prd="0" msr="0" tim="0">986</dp>
    </dpGroup>
    <dpGroup tim="1">
      <dp mkt="0" prd="0" msr="0" tim="1">970</dp>
      <dp mkt="1" prd="0" msr="0" tim="1">937</dp>
    </dpGroup>
    <dpGroup tim="2">
      <dp mkt="0" prd="0" msr="0" tim="2">982</dp>
      <dp mkt="1" prd="0" msr="0" tim="2">955</dp>
    </dpGroup>
  </data>
</dataset>

Ответы [ 2 ]

0 голосов
/ 18 августа 2011

Я думаю, что вы подходите к проблеме правильно. В вашем процессе действительно 2 отдельных шага:

1) преобразовать документ XML в представление класса, модель
2) сделать модель для представления

Часть, где TDD должен хорошо работать, это шаг 2, потому что вы имеете дело с объектами. Затем вы можете следовать по пути, обозначенному Taesung Shin. Вы можете определить интерфейс вашего объекта, если это необходимо, и иметь IChartModel с, скажем, свойством StartDate, которое затем можно смоделировать, установить для StartDate все, что вы хотите, и написать утверждения о том, что должно быть истинно для представления. в таком случае. Как сказал Тэсунг, это поможет вам управлять вашим дизайном.

Часть, где TDD не будет работать так хорошо, находится на шаге 1. Модульные тесты работают, когда вы можете полностью работать в памяти, и по определению файл на диске не работает должным образом в этом контексте. Что бы я сделал тогда, если бы считал, что это стоит затраченных усилий, будет иметь образцы файлов и проверит ваш XmlReader на соответствие этим файлам, чтобы убедиться, что вы читаете то, что вам нужно, и правильно заполнил ввод для шага 2. Это будут не «правильные» юнит-тесты, а скорее интеграционные тесты. Я хотел бы создать «счастливый файл» с правильными данными и, возможно, файлами для потенциально искаженных случаев. Поскольку со временем вы сталкиваетесь с ошибками, вы можете начать добавлять новые файлы. Хотя эти тесты было бы неинтересно писать.

Если вы собираетесь создать этот XML-файл в своем приложении, вы можете рассмотреть возможность проведения тестов, в которых вы создаете эти файлы и читаете их обратно, что может дать вам больше «контроля кода» над происходящим, а не иметь поддерживать фиксированные файлы с течением времени, если ваш дизайн развивается.

Самое большое преимущество, которое вы получили бы, отделяя это, по моему мнению, состоит в том, что, отделяя то, как вы хотите, чтобы данные были структурированы и использованы в вашем приложении MVC, от способа получения этих данных из файла XML, вы будет иметь преимущество разделения на 2 разных уровня, и если вы решите либо извлечь эти данные из SQL, либо со временем изменить структуру вашего XML-файла, у вас будет четкое разделение между доступом к данным и их использованием. , У вас будет модель предметной области (какой должна быть диаграмма), и вы сможете подключить к ней различные источники данных.

0 голосов
/ 18 августа 2011

Сначала я бы сделал самый важный тест:

 Given model representation of xml, 
 when user asks html output, 
 controller should produce correct view with chart/table.

Создание и прохождение этого теста заставит вас задуматься и об общем дизайне.После этого он будет разветвлен и связан.

...