Question

From a WCF service we get a quit complex reponse with multiple nested lists and alot of properties (Up to 5 levels deep). This response isn’t usable one on one, so we built translators that ‘translate’ it to a domain object we can use in our UI.

We want to unittest the translation process so we know that there are is no mismapping between fields. Currently in my unittests i’m building the response in code. But that’s quit some work, especially when i need some variants in the different responses to test the different flows. Also the unittests become very large files. (Only building one response can be up to more than 200 lines)

I have been thinking about a way to make it easier to build up the responses and make my unittests look more clean.

One option i have been thinking about is create for every unittest an XML file with the required response, deserialize this to the response and do my unittests on the deserialized object.

The pro’s of this method are that the unittests will become much smaller, and easier to create. But updating a file/element will be harder. Or at least that’s what I think.

Anyone has some thoughts or different options for making this response building easier?

Answer 1

You can use a framework such as AutoFixture to help you create instances of your response. AutoFixture will set properties automatically, thus making your constructing code really short, and you can override its behavior where needed. Example:

var mc = fixture.Build<MyResponseClass>()
   .With(x => x.SomeProperty, "SomeValue")
   .CreateAnonymous();

For non-customized values, Autofixture uses deterministic randomness to generate the values, which ensures that you get different values each time, but still keeping the values within a valid range.