How should I unit test a “repository” that returns XML?

Question

For a project I have a series of pseudo-repositories that create XML (they aren't true repositories but fill the same role so I've gone with that nomenclature) by calling some XML-returning stored procs. For purposes of my project I also have "Mappers" (again they aren't true mappers...) that take the XML as input and uses Linq to translate the raw XML to DTOs.

Since I have the mapper, it seems to me that the "repository" shouldn't be testing the value returned (since that's the job of the mapper; the repository only cares that it got some XML back, whether or not the XML data is correct). However, this results in tests that are literally just making sure that the return value from the "repository" isn't null.

Basically each repository implements an interface that has a single method called GetXml that returns an XML document. The actual implementation does the database call, but for the test I have a very basic mock class that just returns a blank XML document. Eventually I will need to build up an actual XML file using some hard-coded values for the mock, but is it "okay" that the repository tests are essentially a single line: Assert.IsNotNull(repository.GetXml(), "Xml response was null");

Is this something that should even be tested, or is there a better way to test this without treading on the toes of the mapper? I suppose from a design standpoint I could remove the mappers completely and just have the repository do the mapping itself (or make the mapper internal to the repository). I'm not doing TDD, as I actually have the code written but I'm wanting to create tests so it's easier to test, and so I can show my co-workers the benefits of tests (we don't currently use any type of automated testing).

I guess what I'm really asking it this: Is it okay to write a test that only expresses a design intention to someone who may use the code, without actually caring about the value returned? Right now that's what these tests do: They say, in code, "I should be able to create an XmlXXXRepository class that implements an interface called IXmlRepository , takes a long called quoteID upon construction, and has a method called GetXml() that returns an XmlDocument object" and that's it.

Answer 1

I usually write two types of tests for my XML methods. First I write unit tests for the logic involved with creating the XML result. This usually forces you to extract your logic into another class so that the logic and the XML creation are separated. Which usually means the logic ends up filling in a DTO and the XML is created off of the resulting DTO using some sort of builder class or simple XML serializer.

Once the unit tests all work, I start creating integration tests with a known set of inputs and known XML outputs. Depending on the XML result, this can be either very simple text comparison or a series of XPath queries to validate the structure and the values in the XML.

Oh and the XML assertions in MBUnit are terrific for this kind of testing.