Mocking WCF or SOAP Services

In this lesson, you will learn how to bypass the heavy, network-dependent nature of WCF/SOAP services by utilizing interface-based proxies to mock your external dependencies.

The Problem with SOAP Clients

Legacy SOAP services often rely on auto-generated proxy classes (e.g., Reference.cs from a Service Reference). These classes are difficult to unit test because they are concrete types that directly instantiate network stacks, require complex endpoint configurations, and are tightly coupled to the underlying XML serialization. Trying to mock them directly often results in "fragile tests" that fail because they require a real service to be reachable.

The Interface-Based Solution

To make your code testable, you must decouple your application logic from the generated proxy. You achieve this by introducing an interface that mirrors the service operations and creating a wrapper class.

1. Extract the Interface: Create an IServiceClient interface that matches the signature of the auto-generated client.
2. Implement a Wrapper: Create a class that implements IServiceClient and holds an instance of the auto-generated service proxy. This class delegates the calls to the actual WCF client.
3. Mocking: During unit testing, you no longer inject the WCF client; you inject the IServiceClient interface. Since you now own the interface, you can easily use libraries like Moq or NSubstitute to verify interactions and return canned XML responses without hitting the wire.

// The wrapper approach
public class OrderServiceClientWrapper : IOrderServiceClient 
{
    private readonly OrderServiceSoapClient _client; // The heavy generated class

    public OrderServiceClientWrapper(OrderServiceSoapClient client) => _client = client;

    public async Task<OrderResponse> GetOrderAsync(int id) 
        => await _client.GetOrderAsync(id);
}

By injecting IOrderServiceClient into your business logic, you turn a complex network dependency into a standard interface that your mocking framework can handle with ease. This ensures your tests remain fast, deterministic, and isolated from the volatile state of legacy SOAP endpoints.

Key Takeaway: Never mock generated SOAP client classes directly; wrap them behind a custom interface to enable clean, interface-based dependency injection for your tests.