0

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.

  • My suggestion just create a class with needed properties and use serialization to write/read from file. – Fabio Jul 15 '16 at 14:27

1 Answers1

1

I can't see your implementation but IMO your class looks like an XDocument wrapper, so your unit testing needs to test that your class calls the expected methods on XDocument. I would mock XDocument and verify that the methods you expect are called for Set, Get, Save. Otherwise you will end up trying to unit test all sorts of XML possibilities and XDocument already handles that work.

leetibbett
  • 843
  • 4
  • 16
  • I see what you mean but that would mean I'd also have to create mockable wrappers for XElement, XAttribute etc. I.e. If i call Set("Something.Whatever.SomethingElse", 123) the writer class is going to add a somewhat complex structure consisting of elements, child elements and attributes. I managed to check some important things using an xml schema, but there's still things i have to test. Also, because there are usually many ways to create an xml structure using XDocument, i don't really care if MethodX has been called. All i care for is that the resulting structure is correct. – kevin.keller Jul 18 '16 at 09:17
  • Can't you validate the document by using a schema? – leetibbett Jul 18 '16 at 10:21
  • [This post](http://stackoverflow.com/a/19733388/3407841) has a cool way to validate xml for unit testing – leetibbett Jul 18 '16 at 10:31
  • I'am validating certain things, but there's stuff that i cant really validate. E.g. I'm expecting a certain exception beeing thrown when I'm trying to read an element that doesn't exist. However, I think that post you mentioned probably has a nice approach. I can probably use it to create the basic structure of the xml document and then dynamically add the structure that i wan't to use in my test. – kevin.keller Jul 18 '16 at 10:58