Firebase Unit test

[Joshua Ji]

Hi everyone, 

I recently make a repo that demonstrates unit tests against firebase.

I just want to see how you guys think

It depends on mocha and shouldjs

https://github.com/zirho/firebase-unit-test

thanks

[Alan deLespinasse]

Cool! I take it this runs against a live Firebase database? Have you looked at firebase-server as an alternative? I'm curious about the tradeoffs people have found between those options (or if there are others).

https://firebase.googleblog.com/2015/04/end-to-end-testing-with-firebase-server_16.html

[Joshua Ji]

Hey, 

Thanks for the feedback.

actually I read the post few weeks ago. 

I think I didn't like the idea of mocking anything at the time. But I gave it another try and also went through the actual implementation of FirebaseServer. 

I found that it is not mocking anything. It literally creates a firebase instance on offline mode and runs tests on it. 

It seems it is really good to test things offline. I really love it now. 

I will just use my solution for tests against real server setups and storage interactions.

I really appreciate your feedback.

thanks!

[Kato Richardson]

Hi Joshua,

Just to be nitpicky here, if you're making a round-trip call to the database inside a unit test, it's no longer an isolated test confirming one piece of your coding logic; it has transformed into an end to end test.  When possible, abstracting out the Firebase code to a service or subset of functionality will help to isolate your code logic and make it friendly to unit testing. That's usually where the mocks and stubs come in--by emulating your service/library abstraction layer (e.g. return a fake ListOfWidgets), rather than trying to emulate the SDK (e.g. re-implement the Firebase API). 

When you want to test the service layer that talks with Firebase, then end to end tests are generally much more economical and appropriate. It took me some time to come around to this way of thinking, but I've become an adamant believer that third party tools should be completely isolated from unit testing whenever practical; saves a lot of headache and complexity.

☼, Kato

--
You received this message because you are subscribed to the Google Groups "Firebase Google Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebase-talk+unsubscribe@googlegroups.com.
To post to this group, send email to fireba...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/fc34279b-c5e8-4199-af03-ac659204fc16%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Kato Richardson |

Developer Programs Eng |

kato...@google.com |

775-235-8398

[Doug Stevenson]

I agree with Kato.  Having fully hermetic unit tests that isolate the code under test has two main benefits:

1) It runs faster, with no latency on your network connection (even runs without a network!)

2) In ensures that no external influences can affect the outcome of your test, making them fully predictable (or "less flakey").

That said, there are some times with end-to-end tests (or as I refer to them "integration tests") provide some benefits.

With Realtime Database, if you want to test your authentication and security rules, that's basically impossible to do locally, since all the decision-making is done on the server side.  So, you have to involve the server side if you want to test code that should intentionally invoke a rejected read/write, because it was disallowed by the server.

Also, you may be testing your app's functionality with a blackbox testing framework (such as Espresso for Android), which needs to run in fully "live" environment, backed by a real database.  It can be really handy to check or manipulate the contents of the database at various points during the test, for the purpose of validating the state of the entire environment.  In these cases, it's extremely taxing to mock or simulate every single interaction with the database in order to fully isolate from it.

I'm glad this topic has come up, because I've been thinking a lot about these things from the perspective of Android development.  2017 is a good year for boosting your app's quality!

Doug

To unsubscribe from this group and stop receiving emails from it, send an email to firebase-tal...@googlegroups.com.

To post to this group, send email to fireba...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/fc34279b-c5e8-4199-af03-ac659204fc16%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Joshua Ji]

Hey guys,

I totally hear you and fully understand your points.

I'll keep investigate and experimenting on what we can do more with my approach. 

Thank you all! :) 

have a good long weekend!

[Alan deLespinasse]

Here's a summary what I've found so far in the category of "tools for testing Firebase (particularly Realtime Database) code without using a real live Firebase database connection". I'm pretty much only concerned with JavaScript (client side and Node).

firebase-server tries to be a complete replacement for the Realtime Database backend that you can run yourself for local testing. It seems to have some mechanism for doing authentication, but I haven't figured out how to use it. It tries to enforce database rules (using targaryen; see below), but I'm not sure if that currently works since apparently it is using an out-of-date version of targaryen. (That wouldn't be very useful without some kind of authentication anyway.) You can, however, use it with no authentication or rules; it just allows all reads and writes.

Your local firebase-server instance runs as an actual server in a separate process, and you have to either set up a hosts file to point a domain name at it, or do some bizarre hacking to make the Firebase client connect to "localhost:5555".

MockFirebase looks like it would have been really valuable, but it hasn't been updated since October 2015 and doesn't support the 3.x API. (Firebase-server may have originally been a wrapper around MockFirebase, but I think it was changed at some point and is now a wrapper around the standard Firebase client library running in offline mode.)

A possible alternative to firebase-server and MockFirebase would be to simply use the official client library and put it in offline mode, but this doesn't work in many cases. For example, if you need to test code that does something like this:

db.ref('path').set(1)

  .then(() => {

    doSomething();

  }); 

it won't work in offline mode, because the promise returned by set() will never resolve.

Another alternative is, of course, to inject your own custom mocks into the code you're testing, which I believe is what Kato was suggesting for "real" unit tests.

targaryen looks pretty invaluable for testing database rules offline, assuming it duplicates Firebase's behavior accurately.