Open sideshowbarker opened 9 years ago
Still waiting on reviews for the two PRs linked above. Anyone? @jgraham ?
@inexorabletash you wanna take care of the assert_object_equals
instance in https://github.com/w3c/web-platform-tests/blob/master/service-workers/service-workers/resources/test-helpers.js ?
@sideshowbarker Hrm, I'm not seeing one.
https://github.com/w3c/web-platform-tests/search?utf8=%E2%9C%93&q=assert_object_equals
@sideshowbarker Hrm, I'm not seeing one.
https://github.com/w3c/web-platform-tests/search?utf8=%E2%9C%93&q=assert_object_equals
Sorry, yeah, the URL I pasted in before isn’t for the file I actually found it in locally. The one I found it in locally is service-workers/service-worker/resources/testharness-helpers.js
but I see now that’s an old file laying around in my working directory, and not actually tracked by git.
So never mind about that one :-)
We still have: ext-xhtml-pubid/the-xhtml-syntax/parsing-xhtml-documents/xhtml-pubid-1.html html/semantics/embedded-content/media-elements/track/track-element/cors/support/common.js workers/interfaces/DedicatedWorkerGlobalScope/postMessage/structured-clone-message.html
@jgraham: Is assert_object_equals
still "broken for DOM objects and undesirable in general?" If so, there's quite a bit more cleanup to do. As of 2017-03-26, assert_object_equals
appears in:
/encrypted-media/Google/migrated_to_root_disabled/encrypted-media-keystatuses.html
/ext-xhtml-pubid/the-xhtml-syntax/parsing-xhtml-documents/xhtml-pubid-1.html
/html/semantics/embedded-content/media-elements/track/track-element/cors/support/common.js
/service-workers/service-worker/fetch-request-fallback.https.html
/service-workers/service-worker/navigation-redirect.https.html
/service-workers/service-worker/resources/override_assert_object_equals.js
/service-workers/service-worker/resources/testharness-helpers.js
/streams/byte-length-queuing-strategy.js
/streams/count-queuing-strategy.js
/streams/readable-streams/bad-underlying-sources.js
/streams/readable-streams/cancel.js
/streams/readable-streams/count-queuing-strategy-integration.js
/streams/readable-streams/default-reader.js
/streams/readable-streams/general.js
/streams/readable-streams/tee.js
/streams/resources/rs-test-templates.js
/webmessaging/postMessage_objects.sub.htm
/workers/interfaces/DedicatedWorkerGlobalScope/postMessage/structured-clone-message.html
And confusingly, /webmessaging
also implements its own version, assert_object_equals_
, in /webmessaging/support/compare.js
.
At this point, would it be easier to fix what's wrong with assert_object_equals
in testharness.js
if it's still broken?
@jgraham, is the discussion in https://critic.hoppipolla.co.uk/showcomment?chain=12186 lost forever?
See also #20844.
It seems like assert_object_equals
is broken in several ways. Should it be linted?
Reviewing usage, I note the following patterns in descending order of occurrence:
shorthand for a bunch of property assertions; no need for deep comparison, and even asserting that no extra properties exist is beyond the scope of the test. e.g.
assert_object_equals(actual, {prop1: value1, prop2: value2, ... propN: valueN});
// rewrite to:
assert_equals(actual.prop1, expected.prop1);
assert_equals(actual.prop2, expected.prop2);
assert_equals(actual.propN, expected.propN);
the slightly stronger assertion that there are no additional own-properties, e.g.
assert_object_equals(actual, {prop1: value1, prop2: value2, ... propN: valueN});
// rewrite to:
assert_equals(Object.keys(actual).length, N);
assert_equals(actual.prop1, expected.prop1);
assert_equals(actual.prop2, expected.prop2);
assert_equals(actual.propN, expected.propN);
recursive array comparison, where each element is either an array or can be compared with assert_equals()
true deep-compare cases, e.g. validating postMessage()'s event.data or similar arbitrary payloads
broken usage, e.g. in workers/Worker-constructor-proto.any.js
Given the prevalence of the first two, I'd suggest adding a new simpler function to testharness.js, e.g. assert_property_values()
(better name pls) which handles the most common bulk property comparison cases as a convenience. I think this accounts for 95%+ of current usage, and we can convert those over. We can then rename assert_object_equals()
to something less attractive.
true deep-compare cases, e.g. validating postMessage()'s event.data or similar arbitrary payloads
Does assert_object_equals
do the right thing for these? Would we need a assert_deep_equals
to replace it?
I think those deep-compare cases could probably have a stricter set of assertions in many cases, e.g. after a clone, should be plain-old-objects and own-properties in most cases. But I didn't spend a huge amount of time looking at them to classify them further.
I worry about having a generic assert_deep_equals
for the same reasons that assert_object_equals
is a trap - it sounds convenient but will likely be either more lax or more permissive than the user is expecting, given the subtleties of JS (prototype chain, etc). So I'm in favor of having more specific functions that fail if mis-used, if we can come up with the right set.
FYI I had started classifying these in this spreadsheet. I see that @inexorabletash did a much better job of this than me though really, in that they pulled out some proper patterns!
@stephenmcgruer - hey, nice sheet! More detailed than what I was doing.
Since you've gone through the calls... what's your take on what we should do?
@jgraham, is the discussion in https://critic.hoppipolla.co.uk/showcomment?chain=12186 lost forever?
https://web.archive.org/web/20160402125934/https://critic.hoppipolla.co.uk/showcomment?chain=12186 has it, edited OP.
@stephenmcgruer pointed out to me we wanted to get rid of assert_object_equals in #25083, which I'd totally forgotten about. https://web-platform-tests.org/writing-tests/testharness-api.html doesn't give it as deprecated, either.
See https://critic.hoppipolla.co.uk/showcomment?chain=12186 and https://github.com/w3c/web-platform-tests/pull/2030#issue-96433741. @jgraham @inexorabletash
[critic thread added from archive.org:]
@jgraham posted 2015-07-13 21:50 +00:00
@inexorabletash posted 2015-07-14 16:31 +00:00
@inexorabletash posted 2015-07-15 23:03 +00:00