I have two classes XmlWriter and XmlReader which internally use an XDocument to Store/Read simple values like doubles, strings and arrays.
The XmlWriter class basically looks like this
class XmlWriter
{
internal XDocument document;
Set(string name, double value);
Set(string name, Int32 value);
…
SaveToFile(string filename);
}
Now, if I want to create a UnitTest for the Set(string, double) method, I can easily use the document field to check if the correct elements have been added using XPath.
xmlWriter.Set("something," 123);
var myAddedElement = xmlWriter.document.XPathSelectElement(…);
Assert.AreEqual(myAddedElement.Value, 123);
This method works well for the XmlWriter. The XmlReader, however, is quite tricky to test. As far as I can see, I have two options:
First, I could use XmlWriter to set up the XDocument for the XmlReader's unit test.
//Quick and dirty to give you an idea
writer.Set("something", 123);
reader.document = writer.document;
Assert.AreEqual(123, reader.Get("something");
I don't really like that because now the UnitTests for XmlReader heavily depend on the XmlWriter class. If I break the XmlWriter class, the XmlReader 's unit tests will most certainly fail, too.
Another option that I have in mind is creating the XDocument by hand, which will get quite tedious especially if the XmlStructure is a little bit more complex.
What is your opinion on that matter?
Thanks in advance.