TDD – MockRepositories for WCF Service Factory

When testing the business logic layer you need to fake the data access layer so you have to worry about the database or the connection speed. The following example focuses on the Repository pattern used in the WCF Service Factory, but it can be adapted to other data access layer architectures.

What do you need from a MockRepository?

· To know if certain methods have been called.

· To know what parameters were passed to those methods.

· To know what (fake) results were returned.

The base Repository class that the Data Access Guidance Package helps you create has 6 types of methods: SearchOne, SearchMany, SearchAll, Insert, Update and Delete. The derived Repository classes use these to accomplish various tasks (SearchById, SearchByIDParent, etc). For the tests, we’ll use the same model: a base MockRepository class that will be inherited by the actual MockRepositories. In order to be able to use them instead of the real ones, we’ll extract the interfaces from the real repositories, have the MockRepositories implement them, and have the business actions work with these interfaces instead.

TDD – Test similar objects automatically

When testing you get to spend lots of time writing the setup and validation parts of the unit test. I talked in this post about a way to speed up the setup phase – generate objects that have random data in their value-type properties.

Something similar can be applied to the validation part. Let’s take an example of a service implementation with WCF Service Factory. Normally you receive a request containing Data Contract objects, you translate those into Business Entities and pass them to a Business Action. This may return a result also expressed as Business Entities that the service implementation must translate into Data Contract objects and forward them to the client.

Luckily, you have a recipe for creating entity translators. But if you want to test the service implementation thoroughly you have to make sure that every property gets properly translated and forwarded from Data Contracts to Business Entities and back. This means lots of “Assert.AreEqual(source.MyProperty, destination.MyProperty)”. More, if you add or remove properties you have to remember to add them to the asserts list, or they will not be tested.

One way to do this automatically (at least for the value-type properties) is to compare the properties that have the same name and type in both objects – taking advantage of the fact that most of the time they are identical. The following method accomplishes this for non-array value or string properties. It can be extended for arrays and indexer properties or even to drill down into reference types, but i find it difficult to follow what exactly gets tested or not. It can also be used for objects of the same type as a quick property-by-property equality check (or you can use it inside an overridden Equals(), but you have to remove the “obj1.Equals(obj2)” from the first if).

Message Contracts in WCF and the Smart Client Software Factory

We’re developing a new product and we took the chance to change from ASMX web services to WCF. We’re using the Service Software Factory and the Smart Client Software Factory from patterns & practices. I have to admit we’re not experts in WCF yet, but the best way to learn is to practice.

The Service Factory makes it easy to declare Data Contracts (there is even an option to decorate an existing class), Message Contracts and Service Contracts. Basically, a Service Contract defines one or more Operation Contracts that use the Data Contracts as parameters.

So where do the Message Contracts come into play? The Service Software Factory Help says:

“A message contract is a class that represents a request or response message. While data contracts represent types that are reused across services and operations within a service, message contracts are defined for a specific operation on a service and are not reused.”

This and the example that follows on how to define the Message Contracts led us to think about the Message Contracts more as wrappers for the request and response for an operation.