Unit testing Or Mock Cosmos DB calls
The CosmosDB SDK is not as friendly as it could be when it comes to unit testing (and the CosmosDB SDK team knows it, so it will get better).
Normally, the way you would unit test such code would be to mock the calls that would go over the wire and just return the dataset that you want this scenario to return.
Normally, the way you would unit test such code would be to mock the calls that would go over the wire and just return the dataset that you want this scenario to return.
However here is a list of things that make it really hard for you to test your code.
Problem 1
The
ResourceResponse class has the constructor that contains the DocumentServiceResponse parameter marked as internal. This is bad because even though you can create a ResourceReponse object from your DTO class you cannot set things like RUs consumed, response code and pretty much anything else because they are all coming from the ResourceResponseBase which also has the DocumentServiceResponse marked as internal.
Solution :
private readonly IDocumentClient _documentClient;_documentClient = Substitute.For<IDocumentClient>();
_documentClient.CreateDocumentAsync(Arg.Any<Uri>(), qDoc, Arg.Any<RequestOptions>())
.ReturnsForAnyArgs(Task.FromResult(new ResourceResponse<Document>(new Fixture().Create<Document>())));
