feat(commands): add support for `cy.callFunction()` about cypress-firebase HOT 6 OPEN

Here is an example of what I was mentioning with firebase-tools-extra:

#!/bin/sh
# NOTE: firebase-extra is used since firebase-tools doesn't currently support emulators (see https://github.com/firebase/firebase-tools/issues/1957)
# NOTE: Make sure to set FIRESTORE_EMULATOR_HOST and FIREBASE_DATABASE_EMULATOR_HOST to environment to use emulators

echo "Seeding DB..."

# Update data in firestore with inline data
firebase-extra firestore:set /users/ABC123 -d '{"some": "data"}' && echo "Updated user in firestore"

# Seed data to RTDB from a file
firebase-extra database:update /roles ./data/roles.json && echo "Set roles from file"

echo "Successfully seeded databases"

Notice how you can pass a file path or stringified data if you use the -d flag, just like the firebase-tools API

from cypress-firebase.

Of note: as of firebase-tools v8.5.0 there is now support for using --import with RTDB

from cypress-firebase.

And v8.6.0 adds --export-on-exit. Things in FB Emulator space are maturing!

from cypress-firebase.

I could see this being a feature for sure, but something to keep in mind is that if this is planned to be used for cleanup, like you were mentioning, that may not always get run depending on where the logic is placed. Also, Cypress advocates for only cleaning up when absolutely necessary as mentioned in their Best Practices docs

Something else is that the hope would be that folks aren't creating logic/cloud functions just for cleaning up after tests, but instead testing on an environment that either doesn't need to get cleaned up or is cleaned on some schedule outside of testing. For my team we have most tests run against an emulated environments with the cloud functions actually not emulated so that we can confirm data is written to the DB correctly, then handle testing functions in their own unit tests. This has helped make UI tests less flaky since we aren't waiting on a full round trip, that said, it is more of an "integration" approach rather than full "end to end"

from cypress-firebase.

I agree with 98% of the Cypress best practices. Some of their best practices assume a db that can be simply cleared and restored. There is friction when it comes to working with a more rigid environment like Firebase. Firebase Auth, in particular, don't work that way 😄

I'm not looking to tear down & build up the environment with every single test run. But even the one-time setup needs to be automated for consistency. Adding dozens of users, their roles, their groups....don't want to do that manually. And I don't want to share my dev & test environments with others.

from cypress-firebase.

That is fair, I definitely feel you there! Something to note though is that firebase-tools does have import capability for the Firestore emulator (through the --import flag when booting up emulator with emulators:exec or emulators:start as well as for auth (auth import/export). Also, if you are looking to seed RTDB with data, my team has been using firebase-tools-extra which uses the same API as firebase-tools, but has support for talking to RTDB and Firestore emulators

from cypress-firebase.