there should be base interfaces for mocking on classes with business logic

[MovGP0]

classes with business logic like CloudBlobContainer, CloudStorageAccount, CloudBlobClient, CloudFileClient, CloudQueueClient, and CloudTableClient should have a base interface that allows to replace those classes easily with mocks in unit tests.

[MovGP0]

refers to Microsoft.WindowsAzure.Storage, Version 8.6.0.0

[Izzmo]

Yeah.. this also needs to be done on the new V12 stuff too... like smh.

[amnguye]

HI @Izzmo, if this needs to be done for the v12 stuff please make an issue on the V12 repo so we can address this accordingly :)

[PureKrome]

Link please @amnguye to the v12 repo.

[seanmcc-msft]

https://github.com/Azure/azure-sdk-for-net/tree/master/sdk/storage

All v12 client's public APIs are virtual, allowing you mock them using mocking frameworks like MOQ. Return types can be constructed using the models factors, such as Azure.Storage.Blobs.Models.BlobModelFactory.

[Izzmo]

@seanmcc-msft ah, very true. I didn't catch that. What are the advantages to making them all virtual vs. using an interface?

[seanmcc-msft]

Making public API methods as virtual conforms to our SDK guidelines.

DO make service methods virtual.

[stewartadam]

@seanmcc-msft can you elaborate apart from just the internal guidance to do it? Is it because changes (even pure additions) to interfaces would break all implementing classes in customer code?

Also for anyone else searching the repo and finding no results -- the class needs an 's', BlobsModelFactory.

[seanmcc-msft]

I'm not sure why we chose to use virtual methods instead of interfaces, the One Azure SDK review board made this decision for all new .NET Azure SDKs.

[MovGP0]

Sealing everything and using interfaces for mocking on service classes would be the recommended way. A class should therefore either be abstract or sealed.

For modifying behaviour, one should use the 'composition over inheritance' principle instead.

Opening the class for inheritance and making service methods virtual (open-closed-principle) should be used additionally where it provides a benefit over dependency inversion and composition.

[stewartadam]

To circle back on this, given the policy of:

DO make service methods virtual.

Then I don't expect there to be base classes/interfaces implemented that would provide a clear path forward consumers of the SDK to create unit tests. If the SDK expects users to spawn (mocked) instances using its own factory classes, I'd recommend the SDK providing examples of those factory classes built-in to make the usage clear (at minimum, link to any relevant factory classes required for unit testing in the README.md).

As for what examples should be provided -- I think the callout in the original issue description is a good start: a simple test for CloudBlobContainer, CloudStorageAccount, CloudBlobClient, CloudFileClient, CloudQueueClient, and CloudTableClient.

[PureKrome]

DO make service methods virtual.

and then

don't expect there to be base classes/interfaces implemented that would provide a clear path forward consumers of the SDK to create unit tests.

and

As for what examples should be provided ... CloudQueueClient

Okay. So if the methods are virtual, then you can mock them in unit tests. You don't need interfaces, for mocking ... at least with the Moq mocking framework (which could be fair to say is the most popular .net mocking framework on NuGet).

Example:

• I wish to add a message to an Azure Queue

(all pseudo code. Just quickly wrote something up. missing all null checks, etc. etc. etc).

REF: Azure.Storages.Queue.QueueClient.

public class SomeService
{
    private readonly QueueClient _queueClient; // This is the Azure Queue Client from Azure.Storages.Queue.

    // Constructor.
    // The QueueClient is 'injected' into this class usually via DI/IoC (out of scope of this example code).
    public void SomeService(QueueClient queueClient) => _queueClient = queueClient;

    // We wish to add a message to a queue.
    public async Task SomeMethodAsync(string message, CancellationToken)
    {
        var response = await _queueClient.SendMessageAsync(message, cancellationToken);
    }
}

and now lets unit test this bad boy with XUnit, and Moq...

public class SomeMethodAsyncTests
{
    public async Task GivenSomeMessage_SomeMethodAsync_ShouldSendTheMessageToTheQueue()
    {
        // Arrange.
        const string message = "I love turtles!";

        // Lets create a mocked QueueClient and fake a response when someone sends a message to the queue.
        var response = new Mock<Response<SendReceipt>>();
        var queueClient = new Mock<QueueClient>();
        queueClient
            .Setup(x => x.SendMessageAsync(message, It.IsAny<CancellationToken>())) // Push the message onto the queue.
            .ReturnsAsync(response.Object); // Not sure if you really care about the response object here.

        // SUT: Service Under Test.
        var service = new SomeService(queueClient.Object);

        // Act.
        var result = await service.SomeMethodAsync(message, CancellationToken.None);

        // Assert.
        queueClient.VerifyAll(); // The SendMessageAsync should have been called at least once, because we defined a SETUP condition.
    }
}

Okay .. so that's a quick a dirty example of

• adding a message to a queue
• unit testing that a specific method on the queue class (provided by Microsoft via their NuGet package) was called.

Bonus reamarks: The code above can be improved with error handling and even wrapping the call to the SendMessageAsync inside a Polly 'retry' policy.

HTH.

Final note: current SDK is soooooooooooooooo much better than the original days of the initial/earlier SDK's. We can mock stuff, today. 🎉

[danneberg]

When you write this in your business code:
public void SomeService(QueueClient queueClient) => _queueClient = queueClient;

You have to write this in your business code:
using Azure.Storages.Queue.QueueClient;

Do you really ever want to reference a 3rd party library from your business code. Bad Idea. You have to recompile your code when you: Want to write to an Azure topic or a Service Bus Queue / Wan to write into an AWS Queue.

Solution: Write your own IQueueRepository interface in Business, Implement it in a Repository as QueueRepository and use the Classes from the external library to implement the repository. Unit testing the Repository makes no sense. Unit testing the Business is simple. Mocking IQueueRepository.

Why are the methods virtual? So you can use dependency injection to create exception handling / retrying / logging just by interception.

Hope this gives you some background why the rule: "There is no interface" make sense here.