WCF响应对域对象的单元测试转换

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.

Answer 2

When writing tests for request-response interfaces, the test cases should be written so each case tests the smallest significant part of the request where possible. That is to say, each test case should be testing one significant element of the request at a time.

If you're following this pattern, you can should be able to identify each test case as being one of the following:

Core Cases

A case that defines the "base" from which other tests are constructed. These are always success cases which represent a successful request. You might define a core request in your unit test classes, or if you have several core cases, build the core cases from a common base. In either case, these cases are where you're doing most of the "setting up" of values.

Deviation Cases

A case which is built off a core test case, by changing one of the pieces of information to test a different use case. Usually these are your edge-cases and usually testing for expected failures (ie caller passing bad information).

This essentially boils down to DRY , in that your core cases are defining things which are "common" among your tests cases, so you aren't spending 200 lines setting up the values. Most of your test case inputs should be expressible as "The same as <test case> but with <deviation> ", so you should write them as such.

Answer 3

I think what Lloyd meant is that you take your current code which is responsible for building your response objects and pack it in a separate *.dll so it is just an API or a library which you then can call from within your unit tests. Thus your unit tests will become much simpler. Another benefit of this approach is that you could actually build two APIs: one constructing fake objects and another which queries the real service. Using an interface you could easily switch the APIs through a config setting. You could also try to use a mocking framework like MoQ or smth. if it makes sense in your case.