On 04 Jun 2014, at 00:33, James Graham <ja...@hoppipolla.co.uk> wrote:
> On 03/06/14 20:34, Boris Zbarsky wrote: > >> I'm arguing against Assert.jsm using the commonjs API names. > > And I am arguing against using the CommonJS semantics. If we are adding > new assertions it shouldn't be ones that encourage broken tests. I think this is very subjective and, to be honest, the first time I heard someone say that the CommonJS semantics are broken, even encourage broken tests. The API surface is concise enough to limit the amount of typing and convey the meaning of the method used. They achieved this to closely follow the English verbs of operators used to test an code block. I really don’t see how much closer you’d like to get to 'doing what you say you’re going to do' as far as API semantics go. I realise that this reasoning is subjective too. Furthermore, are the tests we have currently broken? Is there something we need to get increasingly worried about? The reason CommonJS came into view was not because of it’s semantic superiority, but because of its similarity to both the XPCShell-test and Mochitest assertion styles and implementation. This way I thought we could circumvent ppl to get worried about re-inventing the wheel or something like that and view this change as an incremental step to gradually improve the blueprint overlap between the test suites in use. The benefit, IMHO, of incidentally using an assertion API that is widely used by the Javascript community, globally, was a nice side-effect. As a disclaimer, I’m by no means a fan of the CommonJS group itself. I would even go as far as to say that this particular spec is the only one that might survive the sands of time. Mike. _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
