On 2014-06-04, 1:42 PM, Mike de Boer wrote:
On 04 Jun 2014, at 19:20, Ehsan Akhgari <ehsan.akhg...@gmail.com
<mailto:ehsan.akhg...@gmail.com>> wrote:
On 2014-06-04, 5:45 AM, Mike de Boer wrote:
On 04 Jun 2014, at 00:33, James Graham <ja...@hoppipolla.co.uk
<mailto: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.
I wasn’t implying that they’re broken at all, it’s just that James was
hinting at that.
Fair enough. I'll let James speak to that. :-)
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.
I agree and I think that’s how things happened and the way I explained
it above. As with anything that happens in the tree, they can be
reversed if they appear to have been erroneous; back out. If you think
that is the correct thing to do at this point, please file a bug to make
this happen.
Like I've said before, I don't care that much about xpcshell-tests
framework, so I have no strong objection to what has already landed...
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.
It could be that we have a different understanding of the topic at hand,
but we are talking about assertion methods, right? They’re the simplest
of wrappers around comparing ‘a' to ‘b’ with `==` or `===`. I fail to
see how consolidating these methods in a standalone module is at all
about throwing away years of experience.
Here's an example. We know that the way that the SimpleTest's is
function works (using ==) is broken. If that is the problem that we're
trying to solve, we won't need to change the test API at all.
Please understand that I did NOT replace the testing API, it is still
there. The changesets of the bug that cover this work are minimal and
intentionally so.
Everyone can continue writing XPCShell tests the way they were used to.
All the existing tests work like they did before. The assertion methods
are still there and I don’t think they will _ever_ be removed. I’m not
even saying they should be removed.
I understand that. The part I'm discussing right now is extending
Assert.jsm API to mochitest-browser and mochitest-chrome, declaring the
existing SimpleTest APIs there as obsolete, and requiring reviewers to
enforce this for new code.
Again, the implementation of the assertions themselves are still the
same as before, they just live someplace else. Call it CommonJS, call it
UnCommonJS, call it anything you want; things. did. not. change.
I blame this misunderstanding on my apparent inability to explain things
well enough from the get-go. My apologies.
I don't mean to come off too negative, and please note that I'm not
attacking you personally. :-) I'm very much interested in improving
the current situation for our unit tests, but I'd like to know what
problems you're trying to solve for mochitest-chrome and
mochitest-browser. Can you please list those problems?
Thanks!
Ehsan
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
