Mock CloudBlobClient with AutoFac and AutoMock

Question

I'm trying to write unit tests for my AzureBlobRepository. The repository receives a CloubBlobClient in the constructor. I want to mock the client, but this gives an exception:

using (var mock = AutoMock.GetLoose())
{
    var mockClient = mock.Mock<CloudBlobClient>();
}

Cannot choose between multiple constructors with equal length 2 on type 'Microsoft.WindowsAzure.Storage.Blob.CloudBlobClient'. Select the constructor explicitly, with the UsingConstructor() configuration method, when the component is registered.

Ofcourse, in my unit test I am not registering anything, so that message is not very helpful.

I also tried other ways like providing NameParameters, TypedParameters, or calling mock.Create in stead of mock.Mock, but everything I try returns the same exception message.

(same problem also occurs on CloudBlobContainer)

UPDATE after implementing interfaces here is an example of a unit test that I wrote:

[TestMethod]
public void AzureBlobRepository_GetByIdAsync_ReturnsContent()
{    
    Guid blobId = Guid.NewGuid();
    Guid directoryName = Guid.NewGuid();
    string containerName = "unittest";

    using (var mock = AutoMock.GetLoose())
    {
        var mockClient = mock.Mock<ICloudBlobClient>();
        var mockContainer = mock.Mock<ICloudBlobContainer>();
        var mockDirectory = mock.Mock<ICloudBlobDirectory>();
        // notice that we're not using AutoMock here, it fails to create the mock
        var mockBlob = new Mock<CloudBlockBlob>(new Uri($"http://tempuri.org/{containerName}/{directoryName}/{blobId}"));
        mockBlob.Setup(m => m.DownloadTextAsync()).Returns(Task.FromResult("content"));

        mockClient.Setup(m => m.GetContainerReference(containerName))
            .Returns(mockContainer.Object);
        mockContainer.Setup(m => m.GetDirectoryReference(directoryName.ToString()))
            .Returns(mockDirectory.Object);
        mockDirectory.Setup(m => m.GetBlockBlobReference(blobId.ToString()))
            .Returns(mockBlob.Object);

        var repository = mock.Create<AzureBlobRepository>(
            new TypedParameter(typeof(ICloudBlobClient), mockClient.Object),
            new NamedParameter("container", containerName),
            new NamedParameter("directory", directoryName));

        var result = repository.GetByIdAsync(blobId, directoryName).Result;
        result.ShouldBe("content");
    }
}

Answer 1

Those classes should be treated as 3rd party implementation concerns. This means that you have no control over them and we should not mock what we have no control over. They should be encapsulated behind abstractions that you do control and can mock as needed when testing in isolation.

public interface ICloudBlobClient {
    //...expose only the functionality I need
}

public class CloudBlobClientWrapper : ICloudBlobClient {
    private readonly CloudBlobClient client;

    public CloudBlobClientWrapper(CloudBlobClient client) {
        this.client = client;
    }

    //...implement interface wrapping
}

Classes should depend on abstraction and not concretions for that very reason. Mocking concrete classes tend to have knock on effects

The wrapper does not need to wrap the client exactly but can aggregate functionality so as not to expose implementation concerns.

So now when testing in isolation you can mock the abstraction you control

using (var mock = AutoMock.GetLoose()) {
    var mockClient = mock.Mock<ICloudBlobClient>();

    /// ...and the rest of the test.
}