Consider using _.isObjectLike rather than _.isPlainObject within td.object

[traviskaufman]

Given this code:

const td = require('testdouble');

class MyClass {
  doSomething() {}
}

function callDoSomething(myClass) {
  myClass.doSomething();
}

const mock = td.object(new MyClass());
callDoSomething(mock);
td.verify(mock.doSomething());

When run on a browser that doesn't support proxies - such as IE11 - this code will throw an error saying:

Error: Error: testdouble.js - td.object - The current runtime does not have Proxy support, which is what testdouble.js depends on when a string name is passed to `td.object()`.

I believe this to be a false positive, with the offending code being

testdouble.js/src/object.js

Line 16 in c54b741

if (_.isPlainObject(nameOrType)) {

This code uses _.isPlainObject, which returns false for instances of objects whose [[Prototype]] is not Object.prototype. This is problematic for instances of classes, who's [[Prototype]] is the constructor.

I'm wondering if you'd be willing to switch to _.isObjectLike instead of isPlainObject? This will return false for functions / constructors, but true for instances.

I'm able to work around the _.isPlainObject limitation by creating a fake constructor using td.constructor, and then instantiating that instead, but it is a bit more boilerplate.

Thanks!

[searls]

I think you are probably right and that _.isObjectLike is closer to what we desire here.

However, I'd like to understand why td.constructor() isn't a better fit for your needs in this case, given that your fake is an instantiated Something.

[searls]

I dunno. I guess I could go either way after writing this out:

const mock = td.constructor(MyClass);
callDoSomething(new mock());
td.verify(mock.prototype.doSomething());

[searls]

Hmm, there are really three affected areas by this distinction and I think it warrants some thinking before we change anything.

• td.matcher.contains - would have to put regex above and then ask ourselves if there are cases this could screw up
• td.replace, but this seems like it'd be safe since the only other path would be an error
• td.object as you described, proxy is only for string, so i think that makes sense there, but it'd have to be demoted below array.

[searls]

hmm, this isn't quite an obvious fix. If we just swap isObjectLike, the td.object() call still won't work, because such an object will not give up its functions via _.functions so none of its properties will be replaced with doubles.

Probably need to spend a little more time looking at this…

[searls]

I've had the night to reflect on this and I think I want to recommend using td.constructor for any fake custom types, because they'll raise all sorts of issues (beyond the _.functions thing from last night), like getters/setters, etc.

Instead, I'm going to suggest we "fix" this by improving the message.

[searls]

Closing in favor of the approach taken in #264