Indeed I meant to say the following: Taking the CommonJS spec as an umbrella for these simple assertion methods is more of a nice side-effect than it was the primary objective we started off with. I think it helps provide a common, immediate understanding for new contributors who’d like to write test for the code they contribute, as the add-on SDK and the NodeJS community already use it exclusively.
On 03 Jun 2014, at 13:49, Gijs Kruitbosch <gijskruitbo...@gmail.com> wrote: > 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
