On 05 Jun 2014, at 12:00, Dao <[email protected]> wrote: > On 05.06.2014 11:38, Mike de Boer wrote: >> On 05 Jun 2014, at 09:54, Dao <[email protected]> wrote: >> >>> On 04.06.2014 11:45, Mike de Boer wrote: >>>> 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. >>> >>> I don't understand. How does using CommonJS achieve this better than making >>> XPCShell use something based on the Mochitest API? >> >> It doesn’t, per sé. Please understand that I’m not at all attached to _any_ >> API. I care only about pragmatic consistency across test suites we use for >> frontend development. If possible, across the board.
I actually meant ‘test runners’, not ‘test suites’. But we already understood each other :) > > That's a fine goal and apparently generally agreed with (except for > testharness.js). > >> As I tried to explain, the CommonJS API naively made sense to me at the >> time. To others as well, because we’re happily using it. As I now >> understand, some of us are very attached to a specific, different, API. > > While I like that the SimpleTest methods tend to be briefer, I don't think > the main issue is that people are deeply attached to that API per se. The > point is that we shouldn't replace it without good reasons, since there's a > cost attached to switching APIs. If we were using CommonJS and someone > proposed we moved to SimpleTest, there would likely be a similar backlash. I’m a bit wary of the ‘cost’ propositions I hear every now and again. Everything we do has a cost. Having inconsistent APIs across the codebase has a cost. Having this conversation has a cost. Having an assertion method called `ise` has a cost. I’m not sure what you’re trying to discuss here. I want that to happen, which is most ‘cost-efficient’; if that’s moving the implementation of `is`, `isnot`, `ise` to a separate module whilst keeping the method names available to all Mochitest(-browser) tests, than we do that. If providing the SimpleTest API to XPCShell-test by aliasing the assertion method names to the respective SimpleTest method names and not exposing the CommonJS method names in the global scope is most ‘cost-efficient’, than we do that. > >> I care only about the sanity of its implementation. The problems cited by >> James and echoed by Boris concerning `deepEqual()` are thusly most important >> to me[1]. >> >> Renaming `strictEqual` to `equal`, nuking `strictEqual` from orbit, is more >> than fine by me. Or we name it `is`. >> >> (As an aside, whilst maintaining my position of not caring about it, I don’t >> understand why ‘we’ like an ambiguous term `is` better than `equal`.) > > This is the first time I hear the complaint that 'is' would be ambiguous. > This isn't a problem that occurred to me while writing and reviewing tests > over the years. Well, I consider reading it out load in English: is(foo, bar); Should it read "is foo [?] to bar?” or “is foo [equal to] bar?” or “is foo [strict equal to] bar?” or “… foo [is] bar?” equal(foo, bar); Should it read “Are foo and bar equal?”. Mike. _______________________________________________ dev-platform mailing list [email protected] https://lists.mozilla.org/listinfo/dev-platform
