What we set out to do, really, is to test as much of the system through the UI as possible, but we hit problems if we cannot roll back test data in backend systems. The solution is to mock out these backend systems for any operation that cannot be undone.

The system we had to deal with was not designed with this purpose in mind, so we had to find a way of setting up mocks for each test scenario without touching the backend systems involved.

We went for a solution which has 2 major parts: Unity Framework and Rhino Mock. Here in short is how it works: we identified all interfaces on boundaries in the system and “loosened” them. Instead of directly using web service proxy objects, we use interfaces. These interfaces consist of all synchronous methods on the generated proxies so these implement them automatically, but crucially they can also be mocked out. When a call needs to be made, we ask Unity to resolve an instance of the interface instead of instantiating the proxy ourselves. We configured Unity in such a way that by default in the production system the proxies are always instantiated. In effect we have now created a loosely couples application without doing too much work. Even generating the interfaces out of the web service proxies is something Visual Studio does for you via one of the refactoring functions.

When running a test  we can now switch out any of these real proxy objects, and replace it with a mock that implements the same interface. This is where Rhino Mock comes in.

There is one more hurdle to overcome: we cannot easily control mocking of objects behind a web service and since we want to drive everything from the UI, that means we will have to get rid of this limitation. Easier said than done.

There were 2 major options we considered: we could have added web services to the front server during development to allow us to setup mocking of communication with the back end systems or – and this is the option we went for – have the front server running in the same process as the UI test so we could setup mocks in Unity directly.

To achieve this aim we again used Unity. This time we don’t want to mock anything, but we want to bring the web service into the UI process. First we again extracted an interface from the proxy, but then we add the interface to both the proxy and the web service. This will allow us during testing to replace the web service proxy in the UI with the web service class itself, thus bringing it into the same process.

 

 

The image above shows how the production setup is simplified during testing to a single process to facilitate mocking at all points in the system.

In the next part I will discuss further the difficulties we had getting all of this to work, how we solved them with features in Unity and Rhino Mock, and what the limitations are we have found with this way of working.

 

By Nick Verschueren, .Net Solutions Architect