On 03/06/2014 12:27, Mike de Boer wrote:
<snip>
5. Assertion semantics are indeed poorly specified, across the board.
Our switch from `do_check_matches()` to `deepEqual()` even revealed a
buggy implementation there, which we didn’t know about. Apart from
that, it was largely undocumented, not fully covered by unit tests
except for the pathological cases. I’m actually a bit scared of what
I’ll find in Mochitest[3] Type coercion is something specifiable, but
I’m not sure whether that is something `ok`, `equal` and family
should implement guards for. If there’s a wish/ call for more
specific assertion methods like `is_truthy`, `is_falsy` and variants
for all possible coercion traps, I think there’s room in Assert.jsm
to add those. We are in the sad status quo that all assertion methods
in all test suites are underspecified to some degree. The fact that
these methods are an integral part of each suite makes it harder to
change that. Assert.jsm breaks away from that approach to make these
improvements possible to a wider audience. If we agree that more
spec’ing is needed, we might as well fork the spec[2] to MDN and
collectively work it out.
Changing the semantics of things that people are already using seems
like a uphill battle. I think if you wanted to introduce a common set of
assertion names across Mozilla harnesses, starting from CommonJS rather
than starting from a discussion of actual requirements was the wrong
approach.
That’s not what we’re doing here! Changing semantics is a non-goal, merging
assertion methods into one re-usable module is.
Taking the CommonJS spec as an umbrella for these simple assertion methods is a
causality
What are you trying to say here? I don't understand. I believe
"causality" is not the word you want here.
~ Gijs
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
