I’ve often had to use XML documents in my unit testing. In the past, I’ve always done a concatenation to string together a document.
However, I came across a post on Haacked that lead me to a better solution, embedded resources. Basically, you add a document to your project and mark it as an “Embedded Resource” rather than “Content” in the “Build Action” attribute.
This will pack it into the unit testing dll and allow you to extract it from the assembly. No more missing documents causing failing tests! In my custom class, I’ve defined a method for unwrapping the resource that allows you to pass in arguments that it will use for customizing the xml nodes. I found this to be simpler than attempting to navigate the document and update the nodes although I’m guessing it may be less performant.
One thing to be sure of with this, is that you use a centralized location for the resources so that your lookup doesn’t fail. So now I’m able to write my tests such that their intent is clear and the code is clean.
Although I haven’t had the need yet, I could see where this could easily grow into handling multiple types of documents but I’ll hold off on that code until I need it. 
July 10, 2007 at 11:04 am |
Dave,
I write about a very similar problem, solved in a similar way, back in Feb 2006. I often have the situation that I need to access a file on disk for my code. So I wrote an IDisposable wrapper that uses Embedded Resources just as you describe. Details can be found here:
http://www.timrayburn.net/2006/02/19/ExternalFileDependencyInNUnit.aspx
Good content! Keep it coming!
Tim
July 11, 2007 at 6:02 pm |
Interesting that you posted this, as I have just started teaching myself XML this past week … I am surprised at the flexibility and versatility of the language.
July 22, 2007 at 7:56 pm |
We do embedded resources for our unit tests at eInstruction. Some of them are fat, and we started having problems with memory usage inside Visual Studio with R#, so we now have a separate statically referenced assembly with all our test resources in it.
December 13, 2007 at 9:42 am |
Here’s a question: how would you unit test your UnwrapXmlResource method?
I have a very similar method – though it is static – in a standard library – and I have pretty good test coverage on everything except for the extraction of an embedded resource.
Because the method I’m testing is more utilitarian than just for unit testing it expects the embedded resource to be in the “entry assembly” so I use Assembly.GetEntryAssembly().GetManifestResourceStream(resource);
However, with a unit test there is no “EntryAssembly”
Any thoughts?
December 13, 2007 at 12:18 pm |
finalkut: I suppose you could continue to pull pieces out (Assembly, Stream) until you get the thinnest layer possible but at some point you’d simply have to have an integration test that gets you that “last mile”. For me, I’m good with leaving it untested since it’s really only used for testing itself and I’m not interested in falling into “testing recursion”.