On 2014-06-04, 5:45 AM, Mike de Boer wrote:
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?
Define broken. We do have quirks in each of our test frameworks that
we'd do differently if we went back in time and wanted to redo things again.
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.
Well, honestly it seems like we're approaching the problem backwards, by
picking CommonJS first, and then figuring out what the implications are.
I think the right way to approach this is the exact opposite: first
define what the problems that we're trying to solve are, then figure out
what the technical options on solving those are, whether they require
*any* changes to the test APIs, and if so try to justify the changes
very well, get feedback on the proposed goals and changes to satisfy
them, rinse and repeat.
The other thing that you need to note is that there is years of
experience behind each one of our test frameworks, and there are
probably several hundred thousand lines of code written against any of
them. And there are many many people who have been using these
frameworks for years now. Completely replacing the testing API is
pretty much as major a change as one could possibly imagine. This is
not a gradual change in any way.
Cheers,
Ehsan
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
