WCSF – Using Session State in Unit Tests

The Web Client Software Factory provides a handy class, StateValue<T>, to use for storing values in Session. From the WCSF help:

This class supports code that runs both in a Web server environment (the session is available, and data is stored there) and outside of a Web server environment (no session is available, such as when you run your unit tests, and the data is stored in memory).

To use it, just declare a public field of StateValue<T> type and the Object Builder injects the object:

public StateValue<MyType> MyStoredValue;

To access it, just use the Value property:

MyStoredValue.Value = new MyType();

This works fine when running the application in the web server. When unit testing however, you’ll notice that the field remains null, because the object builder used for the MockCompositionContainer lacks the strategy that deals with the StateValue<T> fields. Unfortunately, the Reference Implementation that comes with WCSF doesn’t make use of these type of fields so there is no quick example on how to deal with them in tests. You can use the tests covering the builder strategies from the CompositeWeb application block tests, or you can use the following quick reference and save yourself the digging .

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).

TDD – Create test objects automatically

Unit tests normally have three sections: setup, action and validation. In the setup part you often have to create and initialize objects that will be required by the action and that you can use in the validation part to decide whether the code works or not.

The code might look like this:

      [Test]

      public void DoSomethingWorksFine()

      {

            MyObject obj = new MyObject();

            obj.Text = “test text”;

            obj.ID = Guid.NewGuid();

            obj.Date = DateTime.Now;

            // etc.

            testedObject.DoSomething(obj);

            // asserts

      }

Although normally one or two initialized properties are enough, I consider it a good practice to check that all the fields pass well through the test (especially when you’re testing database repositories or web service calls). The problem is that if you use the default values you won’t know if the test passed just because the result has the same initial values.

My solution is a handy utility class that fills the objects properties with random data: