On 6/6/14, 11:04 AM, Gijs Kruitbosch wrote:
I'm interested in the API exposure case (bug link please? :-)
I'd have to search, sorry. :(
I would have assumed that you would test that kind of thing by checking if the
relevant API property is enumerable from the object, rather than
checking for its value
I would too, but that's not what people put in the test.
Note that at least one of the APIs involved was actually defining the
property always but returning null vs undefined in some cases based on
permissions or whatnot (this was not a WebIDL API at that point).
Put another way, I think that purposefully designing an API where a
return value (or existing property value) has a meaningful distinction
between 0, "", null and/or undefined is essentially a footgun that will
not just hit testwriters but also web authors
I agree, sure. We shouldn't be doing that.
I expect that you tend to write mochitest-plain tests for web APIs.
Indeed.
Those aren't the tests I write the most, which are mochitest-browser or
mochitest-chrome. I can't think of a single case where I care(d) about
the null/undefined/""/0 distinction in those tests, and that is what my
comment is based on.
Sure. But would it cause problems if we did enforce the distinction?
I'll have to see how the try run looks. ;)
It's also interesting that your experience is apparently very different
from roc, who explicitly called out DOM/layout tests as also not needing
these. :-)
Yeah, I've been dealing a lot with edge cases of DOM APIs for the last
year or two....
I guess that if this is actively biting us in terms of providing wrong
test results, perhaps that should weigh heavier than the concern for
ease-of-testing of other code, although I expect that changing the
semantics of these functions after the fact might be an Everest-scale
uphill battle in terms of test failures. :-(
That will be the big question, yes.
-Boris
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
