On 08/16/2012 06:21 PM, Ehsan Akhgari wrote:
On 12-08-16 11:34 AM, Ms2ger wrote:
On 08/16/2012 05:10 PM, Ehsan Akhgari wrote:
I think this is generally a good idea. I have a few questions before
jumping in to agree though.
1. Is the current testharness.js API the documentation at the beginning
of <http://w3c-test.org/resources/testharness.js>? If that is the case,
the API looks a lot heavier weight than the default mochitest API we
use. In that case, would it make sense for us to have a compatibility
layer which translates our mochitest APIs to the equivalent
testharness.js API calls? (I'm not 100% sure if that conversion would
be straightforward.)
I don't feel it's terribly heavyweight. In the simple case, you need a
test(function() {
// tests
});
That's two extra lines of boilerplate. Our mochitest boilerplate is…
(*looks it up*) 30 lines. I think we'll deal. The method names for
assertions (assert_*) are a bit longer than we're used to, but in my
experience, you get used to it rather quickly.
I was not necessarily talking about the size of the boilerblate. I was
mostly talking about the size of the API. The mochitest API is
considerably smaller than testharness.js, and is therefore easier to
read and learn, I think.
I don't really agree that the API is much larger; it's just that all the
assert_* functions are documented, unlike the various functions we
expose to mochitests.
It's of course true that this is another API to learn, but I don't think
it's significantly harder than the mochitest API for people who don't
yet know either.
IMO, it would not be a good idea to try to layer another API on top of
this, because it makes our tests harder to understand and less reusable
by other browser vendors, and it means that experience with our brand of
testharness.js doesn't help much to understand the standard brand.
I would agree if the mochitest API was also huge. We're basically
talking about 3 functions: is, is_not and ok. I don't agree that using
these functions would make our tests any less usable by other browser
vendors. But I understand that in their eyes, these functions may not
be as intuitive as in mine. :-)
How about
SimpleTest.ise()/isa()/typeOf()/isDeeply()/waitForExplicitFinish()/finish()/executeSoon()/expectUncaughtException()/…?
I would argue that functions like assert_regexp_match don't get in your
way if you don't use them, just like SimpleTest.isDeeply() never gets in
my way when writing mochitests. In general, assert_{true,false},
assert_{equals,not_equals} and maybe assert_throws are, in my
experience, sufficient for most test.
I also don't think it would be terribly straightforward, and I think
that having real mochitests, testharness.js-that-look-like-mochitest and
standard testharness.js in our tree would make our testing situation
more confusing than the lessened learning curve would be worth. In
particular, having two APIs that superficially look the same but are
actually built on unrelated frameworks seems a recipe for a lot of
annoying differences in edge cases.
Hrm, which edge cases are you talking about? Let's talk about is(a, b,
"msg") for example. Why do you think there would be cases where calling
is() is less understandable or more error prone than assert_equals?
Excellent example: is(undefined, null) passes, assert_equals(undefined,
null) fails.
However, I was thinking more about the fact that mochitest watches
window.onerror, while testharness.js catches exceptions from the
functions you pass to test(). To me, it seems easier to make sure you
use two different-looking APIs correctly, than to make sure you've got
the right API when one tries to disguise as the other.
On the testharness.js side, we have things like assert_regexp_match, for
example. I would argue that whether or not assert_regexp_match(a,
/foo/, "msg") is more readable than ok(/foo/.match(a), "msg") is very
subjective and depends on what the author of the test is used to see.
I wouldn't disagree.
HTH
Ms2ger
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
