-
Notifications
You must be signed in to change notification settings - Fork 779
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
assert.propEqual not guarded against circular structures #411
Comments
|
@Krinkle want to look into fixing this again? |
@Krinkle I started working on a patch for this, I hope you don't mind (I just wanted to contribute fixing a bug and saw that this one was open yet). I started implementing a fix considering what Krinkle said in his first comment in this issue, but while I was writing tests for the new propEqual method I realised that I was not actually sure about what the method should return in certain cases. For example: function fn1() { return "fn1"; }
function fn2() { return "fn2"; }
var first = { a : fn1 };
var second = { a: fn2 };
assert.propEqual(first, second, "Should they be equal?");
assert.propEqual(fn1, fn2, "Should they be equal here?"); Using the old propEqual, both would be right. I am not sure we wanted to keep the same behaviour as that may not be what the test author would expect. Should we keep it? Furthermore, Krinkle said we should throw a warning whenever the test author supplied a primitive object. I have been inspecting the codebase and can't seem to find what the best mechanism would be for throwing such a warning. Any ideas? Thank you very much |
The
Using In JavaScript, all non-primitives are objects, and that includes functions. A function is definetely special in that it can be "called" using the Either way, functions can be used as objects var a = {};
var b = function() {};
a.some = 'thing';
b.some = 'other thing'; And this is what makes "static class properties" work: function Foo() {
}
Foo.same = 'same';
Foo.but = 'different';
function Bar() {
}
Bar.the = 'same same';
Bar.but = 'different'; .. and if you pass that to assert.propEqual(Foo, Bar); severity: failed
actual: {
"same": "same",
"but": "different"
}
expected: {
"the": "same same",
"but": "different"
} Now, coming back to the original example:
The answer is yes, because |
I'm closing this for now as it was filed about circular structured which I believe QUnit handles adequately now. Please comment or file a new issue with an example if that is not the case. The example of comparing strings with propEqual is understandably confusing, however I argue that it is not problematic given that if the strings are indeed equal as string, they will be equal as objects as well. So it should not cause any test failures. When the strings differ, they are compared as an object becuase that is what propEqual is for. The docs could use improvement here as well to avoid this mistake, but it is otherwise expected. I'm not sure why, but I suppose it's possible someone might even prefer this for some reason depending on what the string is for. Although if one really wanted that, I suppose one could simply use .split('') to and send them as real arrays to propEqual. The result is related to how I would be open to a breaking change in QUnit 3 to throw an error from propEqual if the "expected" parameter holds a non-object. This is also something eslint-plugin-qunit could help with. |
As a result of #343 we got a new "propEqual" method which is usefully capable of comparing object trees in a "constructor-blind" manner, using a weaker semantic than QUnit.deepEqual. However, this method is not up to the standard of the rest of the framework - in particular, QUnit.deepEqual itself offers support for
"propEqual" was implemented using a utility function "objectValues" which performs a clone of the arguments before they are dispatched to QUnit.deepEqual, and it is deficiencies in this algorithm which are responsible for deficiencies in propEqual as compared to deepEqual.
I enclose a screenshot of the results of comparing two string using propEqual. deepEqual by contrast shows a suitable result.

The text was updated successfully, but these errors were encountered: