Interface for CollectionReference, DocumentReference, DocumentSnapshot (etc) to facilitate mocking

[PadmanavAgarwal]

Currently CollectionReference, DocumentReference, DocumentSnapshot don't provide an interface which makes these difficult to be mocked for Unit Testing.

Is there any plan to add the same or any workaround available?

A PR for similar purpose was merged in the Java library : Java PR 3562

[jskeet]

There's no plan for this at the moment, and I'd strongly prefer to do this via fakes rather than mocks (where in this case the client part would have a fake, not CollectionReference itself) - my experience is that it leads to significantly less brittle code.
I'll have a look at the Java code next week and consider how we might do this. If you have concrete examples of the scenarios you'd like to write unit tests for, that will help us to create an appropriate API surface.

[PadmanavAgarwal]

it will be useful if I am trying to write unit tests for a function ( using XUnit ) that fetches a Document from Firestore.
Lets say the method has a block similar to below. I want to test this, without actually hitting the Firestore, so will need to mock these classes (using Moq) :

CollectionReference cref = getCollectionRef();
DocumentReference dref = cref.Document(xxx);
DocumentSanpshot docSnapshot = await dref.GetSnapshotAsync()
.
.
.

[jskeet]

so will need to mock these classes (using Moq) :

I'm saying that "I need to test a scenario" doesn't imply "I need to mock these classes using Moq". If you can set up a suitable FirestoreDb that will return your test data appropriately from queries, that doesn't mean you need to use mocking. Anything that returns the appropriate data would work - and would be less brittle in the face of the precise implementation details of either your application or the library changing.

Mocking is great for interaction testing - "I want to validate that my code calls method X on the interface" - but I very much doubt that you need to write tests of that kind when it comes to Firestore. That's why I'm asking about what your test scenarios really are. Queries? Streaming changes?

[PadmanavAgarwal]

Scenarios : Queries.
I am completely with you. If there is a method that fetches a document from firestore (like the one below), I should be mocking this method itself with an appropriate response :

public object getDocumentData()
{
CollectionReference cref = getCollectionRef();
DocumentReference dref = cref.Document(xxx);
DocumentSanpshot docSnapshot = await dref.GetSnapshotAsync()
if(docSnapshot.Exists)
{ 
 //get data from docSnapshot -> convert -> return
}
}

However, my concern is when I want to write unit tests for this method itself : probably to test if the exists condition is added / an appropriate exception is thrown / conversion logic is in place. I can surely do it by getting the data from Firestore itself. However, I might want to refrain from hitting the db for my unit tests.
Thoughts ?

[jskeet]

I think you're missing my point - I'm talking about writing unit tests for that method, using a fake just for FirestoreDb (or FirestoreClient, potentially). If I were to provide you with a way of populating a database in-memory, and then allowing you to use all the normal code to access it, possibly including some fault injection for "how does my application handle aborted transactions" for example, that should allow you to write test code that is scenario-based rather than interaction-based.

I'm signing off for the weekend, so I don't have time to go into more detail right now unfortunately, but hopefully that gives the gist of what I'm getting at. To put it another way: if you were trying to write tests against a regular SQL database with ADO.NET, would you want to mock every SqlCommand, or just set up an in-memory database containing your test data, that would behave the same way as the regular database? I'd rather use the second option every time.

Note that there's already one option for doing this with Firestore: the Firestore emulator. It's at least good for "half way between unit tests and integration tests" - it would be good to have something even simpler and quicker for very fast unit tests though.

[PadmanavAgarwal]

Was of the opinion that interfaces will help me create that fake/mock for FirestoreClient. 😅
Probably, that was the idea behind the Java PR as well. Will check other options as well.
Anyway, Happy Weekend 😄

[jskeet]

Just as an update - I'm consulting the Firestore team to see if they have any other experience of this.

[jskeet]

The feedback from the Firestore was a resounding "Yes, mocking is generally not productive here." They suggest using the emulator for tests. That's now reasonably easy to set up in C# using the FirestoreDbBuilder. While I think it would be nice to have something even snappier, I'd go with the emulator for now. One advantage of that over us writing our own fake for .NET is that a single emulator will behave the same way regardless of which language accesses it - if that doesn't quite match the real server, just the one emulator needs to be fixed, rather than one per language.

I'm going to close this issue now as I don't believe we're going to make any changes in the repo for this - but do let me know if you need help getting started with the emulator.

[PadmanavAgarwal]

@jskeet thanks for the update.
FirestoreDbBuilder looks good for now. Will update if there is any issue using it in ci-cd pipelines.

[crate-scarter]

I agree with Padmanav. It would be useful to be able to mock out any response from this call instead of calling even an emulated response as it means you can write unit tests around a function and not concern yourself with the actual retrieval portion. We don't want to have to include the Firestore db call in our unit test. If you were doing this with ADO.Net as was mentioned, you absolutely would want the ability to have it return back an object of your desire to test additional logic.

The current workaround is to implement your own wrapper class / interface combo that abstracts away the Firestore call so that you can then do whatever you want using that wrapper to protect your code from having to take a dependency directly on the FirestoreDb. You could abstract that out to any type of DocumentDb and have the appropriate conversion methods in place to be able to pull from a variety of sources if necessary beyond just GCP.