You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
1.6.2 added a patch that modified td.object the traverse the prototypal chain of a constructor and add all methods on it's prototype. This has a side effect for getters defined on the Object type.
Chai.js for example can(if configured) define a getter on Object for the should property to enable a should style assertion API. When accessed chai creates an assertion object using this as the value to conduct tests on. The current behaviour of 1.6.2 I believe is causing an assertion to be created for the prototype object itself. This is then statically assigned to the outputted object.
The following should demonstrate this.
let td = require("testdouble");
let chai = require("chai");
chai.should();
function Vehicle() {}
Vehicle.prototype.drive = function drive() {
};
function Truck() {}
Truck.prototype = Object.create(Vehicle.prototype);
Truck.prototype.loadCargo = function loadCargo() {
};
let fakeTruck = td.object(Truck);
fakeTruck.should.equal(fakeTruck);
// AssertionError: expected { Object (loadCargo) } to equal { Object (loadCargo, constructor, ...) }
This runs on 1.6.1 and throws an error > 1.6.2.
Ultimately I believe the desired behaviour in this instance should be to ignore this particular property when creating a test double object so that the assertion will continue to be generated at the point the property is accessed.
I can appreciate however this is not always the case and am not exactly sure where to draw the line. Something like ignoring all properties on Object seems a little too blunt. Maybe specifying properties to ignore globally.
The text was updated successfully, but these errors were encountered:
Hey thanks a lot for reporting this and explaining it as clearly as you did. That said, I'm still (and always have been) a bit dense about how Chai actually works and would like some more help in understanding what a minimally impactful change would look like to resolve this issue
That's totally fine. I'm happy to have a stab at patching this but don't want to introduce uneccessary side effects that are outside my use case.
There is a way to correct the assertion after being copied from getter but this means testdouble needs knowledge of how chai works which seems the wrong way to approach it. I'm thinking a setting to ignore certain properties might be the best way to go. This keeps the solution generic so it will solve all issues of this type and allows the consumer of testdouble to configure the exact behaviour they need.
I noticed you have something similar already. https://github.com/testdouble/testdouble.js/blob/master/src/object.coffee#L15
I believe you're currently using it to exclude certain methods from being handled by a proxy object. Does this need to be limited to proxies? If so we could expose it publicly to allow it to be configured and use that. This would allow should to be ignored by td.object() allowing it to be handled by the getter defined on Object.prototype.
1.6.2 added a patch that modified td.object the traverse the prototypal chain of a constructor and add all methods on it's prototype. This has a side effect for getters defined on the Object type.
Chai.js for example can(if configured) define a getter on Object for the should property to enable a should style assertion API. When accessed chai creates an assertion object using this as the value to conduct tests on. The current behaviour of 1.6.2 I believe is causing an assertion to be created for the prototype object itself. This is then statically assigned to the outputted object.
The following should demonstrate this.
This runs on 1.6.1 and throws an error > 1.6.2.
Ultimately I believe the desired behaviour in this instance should be to ignore this particular property when creating a test double object so that the assertion will continue to be generated at the point the property is accessed.
I can appreciate however this is not always the case and am not exactly sure where to draw the line. Something like ignoring all properties on Object seems a little too blunt. Maybe specifying properties to ignore globally.
The text was updated successfully, but these errors were encountered: