Vote: use QUnit API or Unit Testing/A

84 views
Skip to first unread message

Kevin Dangoor

unread,
Oct 9, 2009, 10:00:59 AM10/9/09
to comm...@googlegroups.com
I'd like to do a general vote here, rather than a specific vote... by which I mean that both API directions can still undergo modification as we finish the specs. I just want to gauge the interest level in adopting QUnit's API.

Please make a choice between:

1. Adopt an API substantially the same as QUnit's http://docs.jquery.com/QUnit (note that this is API, not implementation and also note that we can extend this API easier than we can change it)

2. Adopt an API substantially the same as Unit Testing/A http://wiki.commonjs.org/wiki/Unit_Testing/A  (and there is some interest in extending this to allow for assertion failures to be logged rather than to halt the test run)


One final note about this: the existence of this API does not keep anyone from using an API that they already have or like. We're choosing the API that any CommonJS compliance tests would use, but otherwise no one else has to use it. My guess is that the API chosen here will be used by more than just CommonJS compliance tests, though.

Kevin

--
Kevin Dangoor

work: http://labs.mozilla.com/
email: k...@blazingthings.com
blog: http://www.BlueSkyOnMars.com

Hannes Wallnoefer

unread,
Oct 9, 2009, 10:14:26 AM10/9/09
to comm...@googlegroups.com
2009/10/9 Kevin Dangoor <dan...@gmail.com>:
>
> Please make a choice between:
>
> 1. Adopt an API substantially the same as QUnit's
> http://docs.jquery.com/QUnit (note that this is API, not implementation and
> also note that we can extend this API easier than we can change it)
>
> 2. Adopt an API substantially the same as Unit Testing/A
> http://wiki.commonjs.org/wiki/Unit_Testing/A  (and there is some interest in
> extending this to allow for assertion failures to be logged rather than to
> halt the test run)

2.

Daniel Friesen

unread,
Oct 9, 2009, 10:20:52 AM10/9/09
to comm...@googlegroups.com
I have a 3rd one.

3. Use doctest to write our tests.
It's easy to use. Doesn't need any discussion over what api to use cause there is no API. Implementation is actually quite a simple addition to a shell. Rhino already has it builtin so all Rhino implementations already have access to it. I already am using it in MonkeyScript for some Binary/C tests.

~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]

Charles Jolley

unread,
Oct 9, 2009, 11:30:47 AM10/9/09
to CommonJS
1 (possibly taking Resig's proposed changes re: equal and equiv to
make it more like the Unit_Testing/A proposal)


On Oct 9, 7:00 am, Kevin Dangoor <dang...@gmail.com> wrote:
> I'd like to do a general vote here, rather than a specific vote... by which
> I mean that both API directions can still undergo modification as we finish
> the specs. I just want to gauge the interest level in adopting QUnit's API.
>
> Please make a choice between:
>
> 1. Adopt an API substantially the same as QUnit'shttp://docs.jquery.com/QUnit(note that this is API, not implementation and
> also note that we can extend this API easier than we can change it)
>
> 2. Adopt an API substantially the same as Unit Testing/Ahttp://wiki.commonjs.org/wiki/Unit_Testing/A (and there is some interest in
> extending this to allow for assertion failures to be logged rather than to
> halt the test run)
>
> One final note about this: the existence of this API does not keep anyone
> from using an API that they already have or like. We're choosing the API
> that any CommonJS compliance tests would use, but otherwise no one else has
> to use it. My guess is that the API chosen here *will* be used by more than

John Resig

unread,
Oct 9, 2009, 11:44:29 AM10/9/09
to comm...@googlegroups.com
I vote for #1.

--John

Dean Landolt

unread,
Oct 9, 2009, 11:57:39 AM10/9/09
to comm...@googlegroups.com
On Fri, Oct 9, 2009 at 11:30 AM, Charles Jolley <cjo...@gmail.com> wrote:

1 (possibly taking Resig's proposed changes re: equal and equiv to
make it more like the  Unit_Testing/A proposal)

1, with the same stipulation.

Kris Zyp

unread,
Oct 9, 2009, 11:58:03 AM10/9/09
to comm...@googlegroups.com

Kevin Dangoor wrote:
> I'd like to do a general vote here, rather than a specific vote... by
> which I mean that both API directions can still undergo modification
> as we finish the specs. I just want to gauge the interest level in
> adopting QUnit's API.
>
> Please make a choice between:
>
> 1. Adopt an API substantially the same as QUnit's
> http://docs.jquery.com/QUnit (note that this is API, not
> implementation and also note that we can extend this API easier than
> we can change it)
>
> 2. Adopt an API substantially the same as Unit Testing/A
> http://wiki.commonjs.org/wiki/Unit_Testing/A (and there is some
> interest in extending this to allow for assertion failures to be
> logged rather than to halt the test run)
>

I don't have a strong preference, but if there is an async support (like
QUnit has), I would like to keep the consistency and simplicity of using
promises rather than proliferation of extra APIs for async causes (I
know, this is what I always harp on). Dojo has done that with its
testing framework, and the consistency that it provide is really nice,
extra async APIs are not needed to do asynchronous actions.
Kris

Kevin Dangoor

unread,
Oct 9, 2009, 12:16:50 PM10/9/09
to comm...@googlegroups.com
On Fri, Oct 9, 2009 at 11:58 AM, Kris Zyp <kri...@gmail.com> wrote:
I don't have a strong preference, but if there is an async support (like
QUnit has), I would like to keep the consistency and simplicity of using
promises rather than proliferation of extra APIs for async causes (I
know, this is what I always harp on). Dojo has done that with its
testing framework, and the consistency that it provide is really nice,
extra async APIs are not needed to do asynchronous actions.

I agree, and let's just say that async is not a part of the proposal at this time...

Kevin

John Resig

unread,
Oct 9, 2009, 1:33:57 PM10/9/09
to comm...@googlegroups.com
I should mention that I'm fine with #1 with the stipulation, as well
(equal is A === B, equiv is deep recursive equivalence).

--John

Chris Zumbrunn

unread,
Oct 9, 2009, 2:33:57 PM10/9/09
to comm...@googlegroups.com
>> On Fri, Oct 9, 2009 at 10:00 AM, Kevin Dangoor <dan...@gmail.com> wrote:
>>> I'd like to do a general vote here, rather than a specific vote... by which
>>> I mean that both API directions can still undergo modification as we finish
>>> the specs. I just want to gauge the interest level in adopting QUnit's API.
>>>
>>> Please make a choice between:
>>>
>>> 1. Adopt an API substantially the same as QUnit's
>>> http://docs.jquery.com/QUnit (note that this is API, not implementation and
>>> also note that we can extend this API easier than we can change it)
>>>
>>> 2. Adopt an API substantially the same as Unit Testing/A
>>> http://wiki.commonjs.org/wiki/Unit_Testing/A  (and there is some interest in
>>> extending this to allow for assertion failures to be logged rather than to
>>> halt the test run)
>>>

Given the two choices, 2.

The way QUnit currently uses equal is borked in my opinion. So,
replacing same with equiv doesn't help.

If we could agree on "equivalent" for equivalence assertion and
"identical" for identity assertion, we could probably find a
compatible API :-)

Problem is, even for me that is getting to be a bit verbose.

Maybe assert.is and assert.eq is better after all.

Problem is, I really disliked assert.ne.

assert.eq, assert.uneq, assert.is, assert.isnt ?

Chris

Chris

Kris Kowal

unread,
Oct 9, 2009, 2:48:35 PM10/9/09
to comm...@googlegroups.com
On Fri, Oct 9, 2009 at 7:00 AM, Kevin Dangoor <dan...@gmail.com> wrote:
> I'd like to do a general vote here, rather than a specific vote... by which
> I mean that both API directions can still undergo modification as we finish
> the specs. I just want to gauge the interest level in adopting QUnit's API.
>
> Please make a choice between:
>
> 1. Adopt an API substantially the same as QUnit's
> http://docs.jquery.com/QUnit (note that this is API, not implementation and
> also note that we can extend this API easier than we can change it)
>
> 2. Adopt an API substantially the same as Unit Testing/A
> http://wiki.commonjs.org/wiki/Unit_Testing/A  (and there is some interest in
> extending this to allow for assertion failures to be logged rather than to
> halt the test run)

1 + nomenclature migration - global module accumulation + punt async

or

2 + common nomenclature + eventally a DSL to support 1 + punt async

I'd love to have interoperability with QUnit on the unit test level
with the given specification, but to do this in a modular fashion (in
the CommonJS modules sense), unit tests would have to be in a test DSL
that injects the QUnit API into each test script. The bike-shedding
on the method names needs to stop, but we are all over the map. I
think we'll ultimately have to agree to support migration to new,
common names in all of our API's, which I do not think would be
onerous even for QUnit, as long as none of the new names are
contradictory. To converge on names, I think we'll have to do fancy
instant run-off voting.

The eventual DSL support requires extensions to the CommonJS module
standard, which I think more than one user has called for, namely the
standardization of loader interfaces, like
require.loader.load(id)(injection).

Summarily, my vote is more like 2 than 1, with emphasis on convergence.

Kris Kowal

Ash Berlin

unread,
Oct 9, 2009, 2:54:18 PM10/9/09
to comm...@googlegroups.com

On 9 Oct 2009, at 19:48, Kris Kowal wrote:

>
> On Fri, Oct 9, 2009 at 7:00 AM, Kevin Dangoor <dan...@gmail.com>
> wrote:
>> I'd like to do a general vote here, rather than a specific vote...
>> by which
>> I mean that both API directions can still undergo modification as
>> we finish
>> the specs. I just want to gauge the interest level in adopting
>> QUnit's API.
>>
>> Please make a choice between:
>>
>> 1. Adopt an API substantially the same as QUnit's
>> http://docs.jquery.com/QUnit (note that this is API, not
>> implementation and
>> also note that we can extend this API easier than we can change it)
>>
>> 2. Adopt an API substantially the same as Unit Testing/A
>> http://wiki.commonjs.org/wiki/Unit_Testing/A (and there is some
>> interest in
>> extending this to allow for assertion failures to be logged rather
>> than to
>> halt the test run)
>

1 unreservedly from me.

chris thatcher

unread,
Oct 9, 2009, 1:54:26 PM10/9/09
to comm...@googlegroups.com
+1 for #1

PS. I've always been a little confused about the definition of 'deep recursive' because it's not immediately clear if it's inclusive of arrays though apparently includes objects properties.  Probably I've missed some concept that makes it obvious why array's are not included or I'm misunderstanding in general the difference described.

Thatcher
--
Christopher Thatcher

Tom Robinson

unread,
Oct 9, 2009, 3:44:24 PM10/9/09
to comm...@googlegroups.com
2

John Resig

unread,
Oct 9, 2009, 4:03:13 PM10/9/09
to comm...@googlegroups.com
In jQuery's implementation it includes arrays as well. If the
properties are === then they're fine, otherwise we check their type,
if they're the same type then we check the properties - works for both
objects and arrays.

--John

Kris Kowal

unread,
Oct 9, 2009, 4:31:17 PM10/9/09
to comm...@googlegroups.com
On Fri, Oct 9, 2009 at 10:54 AM, chris thatcher
<thatcher.c...@gmail.com> wrote:
> PS. I've always been a little confused about the definition of 'deep
> recursive' because it's not immediately clear if it's inclusive of arrays
> though apparently includes objects properties.  Probably I've missed some
> concept that makes it obvious why array's are not included or I'm
> misunderstanding in general the difference described.

One version of the specification treated Array as a special case of
Object, but it was pointed out that checking the values of respective
indicies was insufficient because you can also add properties to
arrays. So, that line was removed and the line about comparing
objects by their respective owned properties catches the array case.

Kris Kowal

Alexandre Morgaut

unread,
Oct 12, 2009, 4:18:39 AM10/12/09
to CommonJS
+1 for #1

or eventually part of #3
not sure we have to impose one API as some different solutions exists
on client side and might be interesting to adapt on server side for
those already using it.
I said "part of #3" because Rhino is not the only Server Side
JavaScript engine ;-)
Reply all
Reply to author
Forward
0 new messages