On 6/3/14, 11:28 AM, Ehsan Akhgari wrote:
On 2014-06-03, 2:17 PM, Gavin Sharp wrote:
I won't argue that a great case has been made :) But I see inherent
value in consistency (both in the implementations and in the
user-exposed API) for assertions across our in-tree test suites (or at
least, across mochitest-based harnesses and xpcshell). Do you disagree?
Not at all. I think what we disagree on is 1) how to address this
inconsistency, and 2) what other things we should take into
consideration while doing so.
I think what's being proposed here so far is being more consistent with
commonjs testing API (which to me seems like a clear non-goal) by just
adding a new API which will only be used in new
mochitest-chrome/browsers but not in the old ones (at least not yet)
without addressing any of the problems with the SimpleTest API that we
are aware of, or any of the issues raised with it (the subjectivity of
the reasonability of the API should not be used to dismiss mine and
Boris' concern on that). So it seems to me like doing what this
proposal suggests is one step back in terms of being more consistent
without any clear added value.
There is a clear win in the ability to reuse, understand, and modify the
common code. I'm willing to wager that a lot of people don't know where
the testing/comparisons code lives. I can't even recall which file(s)
contain is/ok from mochitest and I know more about the hidden parts of
tests than many. Faced with this problem in the past, I have personally
arrived at the conclusion "meh, I'll just code a one-off in my test
rather than improving the code for all." Multiply that by 1000 and you
have a lot of lost productivity and a more bug riddled automation.
Assert.jsm makes logic centralized, consistent, and easy to extend. If
people need a new comparison/testing function, they can add it to
Assert.jsm, where it will be immediately available to multiple test
flavors, causing less cognitive dissonance and fewer wheels to be
reinvented. It should also result in fewer bugs.
FWIW, a lot of this bikeshedding about what effectively boils down to
style could be avoided if we had JavaScript code rewriting facilities
that could atomically change all references. Change in the style guide?
Just do a massive commit that rewrites everything automatically and
enforce style as part of automation checks. That applies to C++ as well.
I hate living in the 90's.
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
