Unit Tests for method returning xmldocument

I need to create a unit test for a method that returns an xmldocument. What should I be validating in such a case? The method checks a database and creates an xmldocument and sends back the data to the client.

Should I look if the xmldocument returned has all expected xml tags? or should I have a Expected.xml file and match the xmldocument returned with this xml file. If I am going by the second approach, then whatever I am searching for is not present in database then this test would always fail. I want to write a test that is not dependent on any pa开发者_运维问答rticular data but should check whether the data returned by the method is proper or not, so I am leaning towards the approach of checking only the tags and assuming that if tags are there and the values in these tags are also correct.

Lets assume i writing this test for a library application that gives a list of all books issued to a particular member. Members are identified by a id and let that be string:

<Member id="">
 <Book>
   <Name>Book_name</Name>
   <Author>author</Author>
   <Due_date>due date </Due_Data>
 </Book>
</Member>

So i need to verify whether my method would return an xmlfile like above. And i need to verify that the tags are correct and it contains value (and not null values).

What do you think should be better approach? If someone has dealt with such situations before, it would be great if you can share your experience.

Thanks,

The problem is not so much the XmlDocument - it's easy to check if this matches the expected output.

Your problem is more to do with the test input data. In this sort of case you either need to run the code against a specially set up test database so that you can rely on it always returning the same data for a given query, or you need to mock the database (call the database via your own class so that you can replace it with some code that simply pretends to be the database and returns the unit test inputs that you wish to try)

Once you can provide well defined test inputs to the method, you can then verify that each test input produces the required test output - a unit test.

If you wish to be less rigorous, then you can check that the database returns an XML document that is in the correct form (contains a key set of elements and attributes), but that still requires you have some valid input data to test with (so you may still need a test or mocked DB) and won't be testing the method as thoroughly.

edit

To answer your edit, you can test if specific bits of an XmlDocument are "valid" pretty easily. e.g. Is the root element "Member":

Assert(doc.DocumentElement.Name == "Member");

Does the root element have a child element "Name" that is non-blank, and has no children?

Assert(doc.DocumentElement["Name"] != null);
Assert(!string.IsNullOrEmpty(doc.DocumentElement["Name"].InnerText));
Assert(doc.DocumentElement["Name"].ChildNodes.Count == 0);

etc.

Will the resulting document always bee 100% identical, or do you need to actually verify data within the document?

If 100%, I would store a file copy of the expected document in the test project, add it to a resource file, and do a straight-up string <-> string comparison.

If specific data, I would store a stripped-down version of the document in the test project in the same fashion, and create a comparison engine that takes two documents and reads through all existing values in one (the stored resource) to corresponding values in the test target.

The 100% version is easier and more accurate if it applies to your scenario.