Where query on nested fields about firestore-jest-mock HOT 6 CLOSED

That said, I actually intend to spend sometime helping this library evolve if possible, just won't have much time to do so for the next months haha

Some PR's and help would be great 😅
I love that others have found this library useful, but it's hard to keep up with it with my day job -- especially considering there are so many aspects to firestore I haven't used, so can't confidently write mocks/tests

from firestore-jest-mock.

You're right, there isn't currently support for that. I feel like this starts to get into the area of "how much behavior do we reproduce?" If we write code in this repo to allow for querying nested keys, then the tests we write against this mock are really only testing this repo and not necessarily firestore or your code.

I just worry we'll spend a lot of time writing a ton of complicated code and users won't actually be testing anything useful

from firestore-jest-mock.

You're right, there isn't currently support for that. I feel like this starts to get into the area of "how much behavior do we reproduce?" If we write code in this repo to allow for querying nested keys, then the tests we write against this mock are really only testing this repo and not necessarily firestore or your code.

I just worry we'll spend a lot of time writing a ton of complicated code and users won't actually be testing anything useful

Interesting, we are pretty much able to test all the Firestore related methods we have, but the ones that use nested fields, we are testing more than simple logic indeed but this library has been quite helpful for us.

One example of changing the code and test structure to make it testable is that this library doesn't simulate the triggers happening either, in that case, what we did was move the trigger logic to specific methods we could test in isolation, in that sense, I agree that adding triggers support could not be as necessary, this case is a bit diff as it is a query clause that is supported Firestore natively so I feel it would be good to have it as well, just like we have collection groups, IN queries and so on.

from firestore-jest-mock.

I can certainly be convinced (have been in the past with other functions here). I guess my question is, what would your test look like. Is it something like:

db.collection('animals').where('species.type', '==', 'mammal').then((snapshot => {
  snapshot.forEach(doc => expect(doc.data().type).toEqual('mammal'));
});

We query for mammals in our nested field and we assert that all the ones returned are of the type: mammal. In my opinion, what is written above isn't a useful test, since it really only tests that firestore-jest-mock wrote a where function that properly filters nested fields. At a quick glance, it looks like a good test, but it hasn't really tested anything. What's important is that you interfaced with the firestore API properly. i.e. expect(mockWhere).toHaveBeenCalledWith('species.type', '==', 'mammal') -- what it returns is irrelevant because you'd never question what firestore returns.

But I admit there are probably use-cases I'm not thinking of, so I'm curious to here your thoughts. I just don't want to get into feature parody hell, as it would take too much maintenance time on this library as Google inevitably updates their APIs and behaviors.

from firestore-jest-mock.

We are actually doing it at a bit higher level, we have a few functions that handle complex logic internally, we have extracted those into specific helper methods as we could, for example, one method gets all the documents for a user that could conflict/overlap in time with one specific event, this helper takes the document to be tested and a user UID, it will fetch all the events for that user in between a date range.

In this specific case, we extracted the internals of this method even more and passed a mocked list of items so we could unit test it, but would also be good to test the parent method that has this part as one of its internals without having to do it via the emulator, this library saves us a lot of time as we can mock almost the whole Firestore stack!

That said, I actually intend to spend sometime helping this library evolve if possible, just won't have much time to do so for the next months haha

from firestore-jest-mock.

Just want to mention here this would be really useful, since we're storing data in a more object vs array approach.

from firestore-jest-mock.