Context proxying doesn't work with Date

Not sure the reason, stepped through the code briefly. Something like this doesn’t work:

test('whatever', context => {
  let { date } = context;

  date.getTime(); // throws.
});

I think getTime() doesn’t like it when the receiver is a proxy.

[lukeed]

Ya I’ll probably have to drop the immutability locker. Was a nice idea but doesn’t seem to be all that viable (sans cloning objects before each test).

If you consider this a must-have, please say so now before it’s too late 😉

[lukeed]

@matthewp I wasn’t talking about Object.create in my last comment 😃 Yes it’s a new object, but as demonstrated in my snippet above, Object.create(context) doesn’t work because (as you’ve pointed out) the context is mounted as a prototype. Any changes (to existing keys) on the Object.create would affect the original context, at which point there’s no immutability protection. That kinda defeats the purpose IMO since the point of context is to pass around shared values – if those are still vulnerable – and only new keys got washed away after each test – then there’s no real point in Object.createing at all. I would be just as well off using local variables inside my test.

Creating a new object and then assigning the keys to that object would then be a copy/clone, and that’s where the performance question comes in. This is what klona is doing, and while it’s currently the fastest of the deep-cloners, including it in a place like before.each would still have some measurable impact on test runtime. Here’s a hodgepodge of a few different metrics – also included plain object creators (pojo, nCreate, oCreate) just to illustrate the cost between them.

While it may be obvious, an important, unrelated callout is that if you ever see Object.create({}), replace that with {} or Object.create(Object.prototype) for free performance boost. We’re talking 2B vs 2M ops/sec~!