Cache endpoints for references

[Grety]

Any modification on ref.child('childname') will not reflect on a childRef which was created from the same URL with adding '/childname'
Code on jsfiddle
This doesn't happen, I guess, because these two refs appear to be two different objects.
However it differs from behavior of Firebase which locks these siblings through a singleton: database.
Complex application might use this behavior and thus prevent from using MockFirebase in vast scenarios without rewriting code.
What about considering a global object to track paths?

[bendrucker]

Yeah I think this is typically a sign of code smell but worth implementing anyway for consistency. It's worth noting that it's not possible to exactly match the native behavior. Implementing this, without using an ES6 WeakMap, creates a memory leak. I'm cool with doing that because I highly doubt anyone's using MF in a situation where that would matter.

[Grety]

I'd say why to worry about memory leaks in a test mock? most likely it won't be noticed... But from consistency point I agree.
But why do you need WeakMap? MF object is a tree. Each node being an MF. What you need is a global object that holds the tree and allows it to grow. new MockFirebase() should not create a new object but return an existing one if it exists in the tree. If the object is missing in the tree than it is created and added to the global tree. The only complicated to maintain scenario comes when a parent ref is created after a child ref... need to change the root of the global tree.
Though I agree not a high priority after all

[bendrucker]

Yeah I'm more just throwing this out there for someone's info if they happen to have a one in a million use case.

Right now you can do this without memory issues. Well, not exactly because of how GC works, but you get the idea.

for (var i = 0; i < 1000; i++) {
  new MockFirebase('Mock://' + i);
}

At the end of the loop all the MockFirebase instances are garbage collected. If you're caching, there are now 1000 instances attached to the cache that can't get garbage collected. But if you can use a WeakMap as the cache store, they can be.

Because it's highly unlikely that people are using a meaningful number of different endpoints. Just explaining why caching as a means for interface consistency (without a WeakMap) can be tricky. In this case I don't particularly care since the one actually serious case is improbable from a practical standpoint (because no one is paying for a ton of separate databases in production).

[katowulf]

Complex application might use this behavior and thus prevent from using MockFirebase

A minor point here and not necessarily a reason not to consider caching, but our goal is not to support complex applications. Our goal is to support isolated unit tests. For e2e testsing (cross-method, cross-class, cross-lib), one should use the real deal and not the mock version.