Test Driven Development for ASP.NET MVC 3 - Parsing XML source file

Hi would like to reach out to the community to gain insight and advice on the approach to Test-Driven Development for the work I'm carrying out.

I am working on a ASP.NET MVC3 project that parses in a physical XML file (containing chart and table data). First the app generates a model representation of the xml nodes. The controller is there to carriy out the application logic,

that ultimately renders to a specific HTML view with charts and tables.

I am thinking that I will be building a model that represents the xml ie classes like dataset,header,dimension etc with appropriate interfaces. Is this the right approach. (Please see below the sample xml)

What sort of units tests would I write? Would I start with unit tests that access the physical XML files (probably not)? Should I stream fragmetns of xml strings into an Xdocument? (isn't that teting .net code?) Presuming I don't want to create concrete XDocument classes, how do I mock out the object eg

First test I want to do (I think) is to load the xml and test the end_Date is correct

I have a XMLHelper Class that loads the xml and returns a class representation of a header with property end date.

So my concrete code would look something roughly like

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

Assert.Ar开发者_如何学编程eEqual("5/06/2011",header.EndDate);

presume that the below XML is used for the stream or file load.

XML Source

<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>

---

I would do the most important test first:

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

Making and passing that test will make you think about overall design too. After that, it will be branch & bound.

---

I think you are approaching the problem properly. There are really 2 separate steps in your process:

1) transform the XML document into a class representation, a Model
2) render a Model to a View

The part where TDD should work well is step 2, because you are dealing with objects. You can then follow the path outlined by Taesung Shin. You can define what the interface for your object is if needed, and have a IChartModel with, say, a StartDate property, which you can then Mock, set the StartDate to whatever you want, and write assertions about what should be true of the View in that case. As Taesung said, this will help you drive your design.

The part where TDD will not work that well is in step 1. Unit tests shine when you can entirely work in memory, and by definition a file on disk does not work well in that context. What I would do then, if you thought it was worthwhile the effort, would be to have sample files, and test your XmlReader against these files, to make sure that you are reading what you should, and properly populating the inputs for step 2. These will not be "proper" unit tests, but more integration tests. I would tend to create a "happy file", with proper inputs, and possibly files for potentially malformed cases. As you encounter bugs over time, you can start adding new files. These tests wouldn't be fun to write, though.

If you are going to create that XML file in your application, you may consider having tests where you create these files and read them back, which might give you more "code control" over what is going on, as opposed to having to maintain fixed files over time, if your design evolves.

The biggest benefit you would get in separating this, in my opinion, is that by separating how you want the data to be structured and used in your MVC app, from how to get that data from an XML file, is that you will have the benefit of a separation in 2 different layers, and if you happen to either decide to pull that data from SQL, or to change the structure of your XML file over time, you will have solid decoupling between data access, and data utilization. You will have a domain model (what a chart should be), and can then plug various data sources to it.