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

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

Я работаю над проектом 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>

unit-testing asp.net-mvc-3 tdd testdriven.net
person gkng1    schedule 18.08.2011    source источник

Ответы (2)


arrow_upward
0
arrow_downward

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

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

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

person Tae-Sung Shin    schedule 18.08.2011

arrow_upward
0
arrow_downward

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

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

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

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

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

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

person Mathias    schedule 18.08.2011