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
Is your feature request related to a problem? Please describe.
We frequently use matchers to assert that a particular set of fields on a POJO matches certain values. For example:
constactual={v1: "1",v2: "2",v3: "3",/* ... */};sinon.assert.match(actual,{v1: "1"});// just make sure v1 has the right value
This comes up most frequently when making assertions about how a function was invoked when the args are combined into a single POJO (which is a somewhat common pattern).
// I plan to spy on this and use it in `sinon.assert.calledWithMatch`constmyFunc=namedArgs=>{const{ v1, v2, v3 }=namedArgs;// ... do something with v1, v2, v3 ...};
However, if any of the values is a very large, deeply nested object, then a matcher failure will attempt to print the entire object deeply, regardless of whether the match failure was present in that object. When the object is large enough, this can take long enough that it's unclear what's going on and what you've done wrong.
Describe the solution you'd like
The matcher should make an attempt to give feedback only on the parts of the object that were mismatched. For example:
Match failure:
{-simple: "B",+simple: "A",deeplyNested: (matched)}
Describe alternatives you've considered
I've discovered that the problem can be avoided by adding a toString method to the large deeply nested object. This helps, but is a losing battle; I can't anticipate all the large objects out there that might cause this problem.
Additional context
I'm using Sinon 9.2.0.
Example repro:
importsinonfrom"sinon";constmakeDeepObject=(numFields,nestDepth)=>{constdeepObject={};if(nestDepth===0){returndeepObject;}for(leti=0;i<numFields;i++){deepObject[`field_${i}`]=makeDeepObject(numFields,nestDepth-1);}returndeepObject;}/** * Function to assert spy behavior on * @param {{ value1: string, value2: object }} namedArgs */consttestStub=sinon.stub();constdeepObject=makeDeepObject(10,4);// make a pretty large objecttestStub({value1: "Foo", deepObject });// Successful match - is fastsinon.assert.calledWithMatch(testStub,{value1: "Foo"});// Failed match - is slow, presumably due to printing deep objectsinon.assert.calledWithMatch(testStub,{value1: "Bar"});
The text was updated successfully, but these errors were encountered:
Thank you for taking the time to explain the issue with this level of detail. I have experienced the same problem before, in my case with http request objects on node.
It's not a trivial change though. I think we'd have to create a deep copy of the actual object, using the matchers as selectors for what to copy. I'd really like to see this happen though. I think it's worth trying.
Should you be interested in implementing this, I'm here to help. Otherwise I'll get to it eventually.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Is your feature request related to a problem? Please describe.
We frequently use matchers to assert that a particular set of fields on a POJO matches certain values. For example:
This comes up most frequently when making assertions about how a function was invoked when the args are combined into a single POJO (which is a somewhat common pattern).
However, if any of the values is a very large, deeply nested object, then a matcher failure will attempt to print the entire object deeply, regardless of whether the match failure was present in that object. When the object is large enough, this can take long enough that it's unclear what's going on and what you've done wrong.
Describe the solution you'd like
The matcher should make an attempt to give feedback only on the parts of the object that were mismatched. For example:
should print something like
Describe alternatives you've considered
I've discovered that the problem can be avoided by adding a
toString
method to the large deeply nested object. This helps, but is a losing battle; I can't anticipate all the large objects out there that might cause this problem.Additional context
I'm using Sinon 9.2.0.
Example repro:
The text was updated successfully, but these errors were encountered: