On 06/06/2014 15:26, Boris Zbarsky wrote:
On 6/6/14, 7:12 AM, Gijs Kruitbosch wrote:
No, I think that in 99.99% of cases, I don't care about the type, and
therefore I would normally use is() and not care that it's using
non-strict equality. I think the case where there is (a) a possibility
that I could get '5' instead of 5 when code is malfunctioning, and (b)
that would be a bug, is extremely rare
The common cases where this would be a bug are not 5 vs '5'. They're
null vs undefined (the most common; we've accidentally exposed APIs when
we thought we had a test for them not being exposed because of this
one!) or 0 vs ""/null/undefined.
I'm interested in the API exposure case (bug link please? :-) ). 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, which wouldn't be liable to issues with
strict/non-strict semantics if the property happened to be there but
0/""/null.
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, and we should avoid such
intricacies if at all possible. (I recognize that we have to live, to a
certain degree, with an existing set of web APIs where that is sometimes
the case, but I would expect those edgecases to be covered by typeof
rather than strict equality checks where possible (hello, null and new
String() objects...) to make these intricacies as obvious as possible).
and therefore that extremely rare case should require the additional code
The problem is, the rare cases are the ones test writers never think about.
The is() using == thing has bitten us far too many times. I'm just
going to work on getting it fixed.
I expect that you tend to write mochitest-plain tests for web APIs.
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. Tests I write tend to be based on "click X, then
check if Y happens", rather than "poke interface X and see if it returns
Y", which probably leads to different expectations of what tests test
and how they use these comparison functions.
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. :-)
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. :-(
~ Gijs
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
