-
Notifications
You must be signed in to change notification settings - Fork 201
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Testing database functions locally #4
Comments
Hey malikasinger1, you can check out our documentation for how to write unit tests: https://firebase.google.com/docs/functions/unit-testing Google Cloud Functions also open-sourced a local emulator, and we are working to build a tighter integration with Cloud Functions for Firebase. In the meanwhile, you can check it at here: https://github.com/GoogleCloudPlatform/cloud-functions-emulator/ |
This comment was marked as abuse.
This comment was marked as abuse.
Hey Inzamam, thanks for the clarification. I accidentally copied and pasted the unit testing link twice. I've revised my response above. The emulator does allow you to run functions locally. Here's the documentation that explains how to use it: https://cloud.google.com/functions/docs/emulator |
How this emulator support the firebase specific parts of GCF (i.e. |
Hey @atomicleopard this is something that we are still working on. Stay tuned! |
hi @laurenzlong any updates on firebase integration in the emulator? |
@stephenhandley Just released! https://github.com/firebase/firebase-tools/releases/tag/v3.8.0 |
@laurenzlong awesome thanks! |
Any update on the local Database events @laurenzlong? |
Thanks for the follow up! We're prototyping it right now. Would love everyone's feedback on how you would prefer to invoke the emulated database function. Would you rather it be listening to your production database? A test project's datebase? Invokable through a terminal command? |
+1 for through a terminal command Thanks for the great work @laurenzlong |
We're using separate projects for production/sales/Dev/Dev2 . |
@laurenzlong I'm using a separate 'root' within the same project (e.g. Btw, thanks for being so responsive and inclusive on this! 🤘 firebasers 🤘 EDIT: is this along the lines of what you mean by the terminal command?: |
I think the locally deployed database function should definitely listen on a real database rather than being invoked through some terminal command. Whether it listens on a production or test DB would be up to the developer, they should be able to choose which database by calling I like @ahaverty's suggestion that when you run a database function locally, it could send a message to firebase to temporarily disable the cloud listener for the same function, and when the local function listener disconnects the cloud function automatically would take over again. That may not be necessary in all cases though, since it may be innocuous to have multiple listeners on the same node depending what the function does. Perhaps a command line switch could specify whether to temporarily disable the cloud function, and by default it would not. Something like:
This would disable the cloud listener of If you omitted the If |
Also, @laurenzlong, since this issue is actively being discussed and worked on, perhaps it should be re-set to open.... you closed it on March 13. |
I like the sound of that @jaufgang , perhaps cloud disabling true by default though as keeping cloud functions running wouldn't be a use case for us right now and may cause confusion with novice users in future (but we could live with either! 👌) |
Seems a bit sketchy to disable a managed environments distributed event
triggers because a script is running somewhere on another machine. If this
went wrong it would be very hard to isolate, and hard to coordinate within
a team.
One of the challenges of firebase functions is that if you miss a write
event, your chance to process is missed entirely without being recorded,
and this would exacerbate this problem.
I've also found that in practice debugging functions as it stands isn't the
same as normal operations, because you're generally triggering data writes
yourself in the firebase database viewer. This means any operations using
the admin sdk inherit different permissions than real usage.
Being able to push data in locally without impacting a deployed environment
is a great first step, and would facilitate basic testing, which would be a
huge win.
…On Sun, 11 Jun 2017 at 4:28 am, Alan Haverty ***@***.***> wrote:
I like the sound of that @jaufgang <https://github.com/jaufgang> ,
perhaps cloud disabling true by default though as keeping cloud functions
running wouldn't be a use case for us right now and may cause confusion
with novice users in future (but we could live with either! 👌)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#4 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABQdDnc33h7oZBBTOJJYdKK8gHcx0CQbks5sCuBfgaJpZM4MaKU0>
.
|
@atomicleopard Firebase uses pub/sub for events, I've had functions fail before and still handle 100% of events, after coming back online after 1 hour. Although, I do agree with you, it could very easily get messy if one of the team left their local cloud-disabling test on and went out for an hour lunch break! |
Thanks for the thorough feedback everyone! To answer your questions, a terminal command would probably look something like:
Thanks for sharing the perspective that "intercepting" live traffic with a test function could be disastrous for teams. For testing against a real database, I imagine there being a test project that is the default project for "firebase serve". So both hosting and functions would use the test project. This way, you can test interactions like a) user fills out a form and that data gets stored to the database b) a function is invoked and transforms that input c) function writes back to the database d) the new database value affects the web page UI somehow. The test project can be set using "firebase use --add", or maybe it can be a part of the "firebase init" flow. If a test project is not set, then "firebase serve" would use the production project but give a warning?? I'm not sure about what's best in that case. Supporting the terminal command is achievable in the short term, but supporting real database triggers would take more time. |
That terminal command looks slick; I for one would definitely love to use it! Especially if the |
@laurenzlong sounds good 👏 We're working on entirely separate firebase projects for multiple different projects (dev + our main production), so the test target wouldn't be as beneficial, but would also be no harm to have the option either. ..Unless I'm misunderstanding what 'test project' means? Does that mean another firebase project to target, or is it a local version of the Firebase database? If it's just a target option, wouldn't it make more sense for people to set up their target configurations properly and avoid the chance of writing to their production db's? |
Would it be possible to add the ability to allow/disallow local testing against a real database using a new rule added to the rules.json? Either that or some other console setting? Production databases could be configured to disallow it, while dev/test databases could allow it. Also, WRT @atomicleopard's concern about isolating problems if/when they occur, perhaps that could be mitigated by adding messages to the functions log whenever a local function attatches/detaches a listener. |
@mismith Interested to hear how/why the self-refresh would be beneficial for you? (assuming you mean take all the data at the defined ref and simulate pub/subs) Have you considered piping a cat command into ..Most of my testing involves creating it once via one of our client apps, exporting to json, and reimporting via the console. Not too bad right now, but this would be nice 👌 ..Actually. @laurenzlong the ability to create a native firebase .push() on the path would be amazing too! |
@ahaverty Re: manual/invoked refresh: one of my functions sends an email whenever a key is updated (e.g. |
A few wild ideas:
Local testing: in addition to the proposed, it would be great to invoke the
function while watching a file so I can edit it and see it trigger like it
might from the real DB.
Live system: i'd like to see something like the ability to breakpoint the
remote code, possibly even edit it while deployed (so a mini IDE basically).
That way, my full dev cycle could be:
* Write and debug locally using simple data or data I export from firebase
db
* Unit test (assert output/changes)
* Integration test (validate remote systems trigger correctly, such as
sending an email etc - I'm sure more advanced tooling is required here but
its a great aspiration)
* Deploy to test environment, ensure correct functioning
* If not, breakpoint and debug, make 'live' changes to validate fixes
* Apply locally and redeploy/repeat
* Deploy to production
* 🙌 + 🍻 all around
…On 13 June 2017 at 04:06, Lauren Long ***@***.***> wrote:
Thanks for the thorough feedback everyone! To answer your questions, a
terminal command would probably look something like:
firebase serve
firebase functions:invoke:makeUpperCase /input/path -d '{"word":"foo"}'
Thanks for sharing the perspective that "intercepting" live traffic with a
test function could be disastrous for teams. For testing against a real
database, I imagine there being a test project that is the default project
for "firebase serve". So both hosting and functions would use the test
project. This way, you can test interactions like a) user fills out a form
and that data gets stored to the database b) a function is invoked and
transforms that input c) function writes back to the database d) the new
database value affects the web page UI somehow.
The test project can be set using "firebase use --add", or maybe it can be
a part of the "firebase init" flow. If a test project is not set, then
"firebase serve" would use the production project but give a warning?? I'm
not sure about what's best in that case.
Supporting the terminal command is achievable in the short term, but
supporting real database triggers would take more time.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#4 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABQdDnam6xCQKEsYPY3NY-7f1LpmHAJMks5sDX43gaJpZM4MaKU0>
.
|
@laurenzlong Thanks for all the updates. I completely agree with @jaufgang that a locally deployed database function should listen to a real database. I know that'll take a bit more time than the terminal commands, but I'm wondering if it's a priority and being worked on? If it's longer term, how long do you estimate until a solution is ready? Are we talking weeks or months? |
Thanks for the feedback and lively discussion everyone! I see people are divided on the issue of whether local functions should be triggered with the real database tied to the project. What if this was an opt-in behavior? It would not happen by default, but would only happen with an additional flag or something, so you are explicitly telling the CLI "This is not my production project, it is ok to trigger local functions with real database writes". And doing this would stop deployed functions from firing while the local functions are still running. @fej-snikduj We'd be talking about months due to the complexity involved. I think we will likely do both (triggering local functions with mock events and with real database events). They serve slightly different use cases - mock events are great for testing without side effects, and real database is useful for end-to-end integration testing. @atomicleopard thanks for the ambitious ideas! No ideas are too wild ;) In terms of breakpoints, we are actually working on supporting breakpoints in locally deployed functions so that you can debug them from an IDE. @ahaverty Supporting json files is a great idea. If we were to do it, I'm thinking it would make the most sense to be consistent with the usage of firebase:database: commands. So it would look like: @mismith What do you think about invoking the function with sample foobar data if there was no data passed in via the flag? Trying to invoke it with the existing data would require the CLI to actually read the database to see what data is there -which would be slow. As well, the same data would not actually trigger the function, since only update/create/delete events will trigger a function. |
I love this idea. Especially if I could similarly pause deployed functions from running through an API or the Firebase console. While my returning of promises has improved, I still have the occasional deployed function go wild and it would be great to have a panic button. :-) |
@laurenzlong I doubt the dummy data would be that useful (for me) since its form wouldn't be predictable, so I'd probably just end up using/generating my own and passing it via the JSON file or as an inline object. The second half of your last paragraph is kind of worrisome though: if 'writing' the same exact data wouldn't trigger an All this said, I'd still be super happy just to see any of this being made usable soon; I'm being picky when I should really be grateful! |
Thanks, @laurenzlong. Any updates for supporting database events? |
Thanks for following up @msjaber , we've done the first step, which is to enable the Google Cloud Functions emulator to support all event types: googlearchive/cloud-functions-emulator#121. You can use it now, and instructions are in the PR. I'm now working on integrating this into the Firebase CLI, with a repl-like interface to invoke these emulated functions. I've been running several usability tests to make sure we get the experience right before releasing. |
I've developed firebase-functions-local to help with my own testing while the firebase team finishes off their own version. It's handy because you can test without uploading the functions which makes the dev cycle much quicker. You can also attach a debugger to help you get a better idea of what is going on. All triggers run off live data in the realtime database. If you have a smaller app you could even use this as the back-end for pesky functions that don't get touched often when you want to still have a lower response latency than the cloud function warmup time. Once they start getting hit often it's straightforward to migrate them to the cloud. |
Just made a PR to firebase-tools to the emulation of all even types, and a shell to invoke them: firebase/firebase-tools#428. @Crazometer this is really neat! Thanks for sharing. My PR uses fake data, whereas yours uses real DB events, so they complement each other quite well and are useful for different scenarios. |
@laurenzlong I'm curious, so I looked over your PR—and maybe I'm missing something or confused—but why/how do the following two lines perform distinct actions?
i.e., why does the first invoke a Also, is the following a typo or, if not, what does the
|
@mismith
Then in the shell:
As for auth, it is {admin: true} or {admin: false} or {variable: {uid: 'abcd' }}, |
@laurenzlong Re #1, of course! My oversight. For #2, if it should indeed be (the ES2015 object literal property value shorthand syntax-using) |
@mismith Oh yes, that is indeed a typo, sorry! It is a nested object: {auth: {admin: false}} |
@laurenzlong I would love to allow by CLI parameter to choose production/testing database. |
@laurenzlong Is it possible to locally debug/breakpoint functions started by It looks like it's possible for https functions using serve, but I haven't found anything about breakpointing realtime database functions, other than a few comments on this issue 🙌. |
If it works on firebase serve, it should work on the functions shell as well since the underlying emulation mechanism are the same. We haven't done a full survey of all IDEs to know that this would work properly on all of them, so there may be kinks. (But it is on our roadmap to address this and make sure breakpoints always work) |
Hi @laurenzlong - I have looked at the links and stackoverflow and can't get firebase functions debugging in VS code to work. Do you have any new links to get more information/help? It feels like a huge step backwards to debug with console.log 😅 |
@dauledk We currently don't officially support IDE debugging. This is on our radar, but we haven't had a chance to make it work. |
@laurenzlong Would there be a way to hook up the emulator for functions to firebase-server? |
hi @laurenzlong I have a noob question. I wrote a firebase function which are triggered by my application directly not by http request. Can we test it by running function locally? i managed to run function locally but I couldn't find a way to trigger the function. Can you guide me a bit? thx in advance. |
@laurenzlong thx for your response. actually I've read that page, but couldn't make it. I want elaborate more so you understand me better and I run the function locally using Cloud Functions shell according to this link |
Thanks for clarifying, we don't yet support local testing of HTTP callable functions, but that's coming soon. |
Thx ;) |
Hi can I hijack this thread to ask if it is possible to pass authentication to https callabale when testing from firebase shell? if I do |
Not yet. But coming soon. |
@laurenzlong I realize this issue is years old, but I'm coming from GCF (and Functions Frameworks for local development) and now am writing my first Firebase Function as I want to listen for background events from my RTDB. In 2021 is there no way to listen for remote / production database events when using the emulator? Thank you. |
It looks like firebase cli tool bundles all dependencies and upload it to firebase just like aws lambda function does. But it takes too much time to be done even on minor changes in code and also need a good connectivity of internet . If you are offline for some reason, you are just in dark what code you are writing until you have a way to execute and test that functions offline on your local machine.
Is there any way to test firebase functions locally?
if there is no, then why?
The text was updated successfully, but these errors were encountered: