ASP.NET MVC 3 的测试驱动开发 - 解析 XML 源文件答案

【问题标题】：Test Driven Development for ASP.NET MVC 3 - Parsing XML source fileASP.NET MVC 3 的测试驱动开发 - 解析 XML 源文件
【发布时间】：2011-08-18 01:33:46
【问题描述】：

您好希望与社区联系以获取见解和建议关于我正在执行的工作的测试驱动开发方法。

我正在开发一个解析物理 XML 文件（包含图表和表格数据）的 ASP.NET MVC3 项目。首先，应用程序生成 xml 节点的模型表示。控制器用于执行应用程序逻辑，
最终呈现为带有图表和表格的特定 HTML 视图。

我在想我将构建一个模型来表示 xml 即类，如数据集、标题、维度等合适的接口。这是正确的方法吗。（请参阅下面的示例 xml）

我会编写什么样的单元测试？我会从访问物理 XML 文件的单元测试开始（可能不会）吗？我应该将 xml 字符串的片段流式传输到 Xdocument 中吗？（这不是 teting .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

【解决方案1】：

我会先做最重要的测试：

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

进行并通过该测试将使您也考虑整体设计。之后，它将是分支和绑定的。

【讨论】：

【解决方案2】：

我认为您正在正确地解决问题。您的流程中实际上有 2 个独立的步骤：

1) 将 XML 文档转换为类表示，即模型
2）将模型渲染到视图

TDD 应该可以正常工作的部分是第 2 步，因为您正在处理对象。然后，您可以按照 Taesung Shin 概述的路径。如果需要，您可以定义对象的接口是什么，并拥有一个带有 StartDate 属性的 IChartModel，然后您可以对其进行 Mock，将 StartDate 设置为您想要的任何内容，并编写关于视图应该为真的断言在这种情况下。正如 Taesung 所说，这将帮助您推动您的设计。

TDD 不能很好地工作的部分是第 1 步。当您可以完全在内存中工作时，单元测试会大放异彩，并且根据定义，磁盘上的文件在这种情况下不能很好地工作。如果您认为值得付出努力，那么我会做的是拥有示例文件，并针对这些文件测试您的 XmlReader，以确保您正在阅读您应该阅读的内容，并正确填充步骤 2 的输入。这些将不是“正确的”单元测试，而是更多的集成测试。我倾向于创建一个“快乐的文件”，其中包含适当的输入，并可能为潜在的格式错误的案例创建文件。随着时间的推移遇到错误，您可以开始添加新文件。不过，这些测试写起来并不有趣。

如果您要在应用程序中创建该 XML 文件，您可能会考虑在创建这些文件的地方进行测试并将它们读回，这可能让您对正在发生的事情有更多的“代码控制”，而不是让如果您的设计不断发展，则随着时间的推移维护固定文件。

在我看来，分离这个最大的好处是，通过分离你希望数据在 MVC 应用程序中的结构和使用方式，以及如何从 XML 文件中获取数据，是你将受益于 2 个不同层的分离，如果您碰巧决定从 SQL 中提取该数据，或者随着时间的推移更改 XML 文件的结构，您将在数据访问和数据利用之间实现可靠的解耦.您将拥有一个域模型（图表应该是什么），然后可以将各种数据源插入其中。

【讨论】：