On 03/06/14 00:24, Chris Peterson wrote: > On 6/2/14, 3:42 PM, Ehsan Akhgari wrote: >> 2. I also value consistency more than my personal preferences, and based >> on that, using the existing APIs in some tests and the new APIs in other >> tests (even if we agreed that #1 above doesn't matter) is strictly worse >> than the status quo. > > btw, in the mozilla.dev.tech.javascript-engine.internals fork of this > thread, bz and David Bruant pointed out that W3C's testharness and > TC39's test262 each use yet another set of assertion function names. Any > tests we import from those test suites will need glue code to integrate > with our test harness(es).
In fact, for testharness.js tests (and the W3C web-platform-tests in general) the plan is to have a dedicated test harness (bug 945222). This is already up and running on tbpl on Cedar and will be turned on for mozilla-central as soon as the intermittents are under control (Linux is looking good, Windows has some issues with WebVTT tests, OSX shows a little more variability). As a result, in the near future we won't need glue code between testharness.js tests and other kinds of tests. FWIW I think the main problem with the CommonJS assertions is their their semantics. For example: * Test assertions shouldn't silently type-cast, but ok, equal and notEqual all do that. Their brevity compared to strictEqual and notStrictEqual means that they are likely to be much more widely used. * notStrictEqual and notDeepEqual are terrible names that actively mislead about what the functions do. * deepEqual has, as far as I can tell, underspecified semantics. I can't tell if it is supposed to recurse into nested objects and, if so, whether there is supposed to be be any loop prevention (the spec talks about "equivalent values" for every key, without defining what this means). * throws doesn't seem to provide any way to test that the type or properties of the thrown object. I know we have test harnesses using assertion functions that already have some of these problems, but I don't see the benefit of adding a new set of methods with exactly the same issues. _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
