Vote: use QUnit API or Unit Testing/A
Kevin Dangoor
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
> 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)
Daniel Friesen
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
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:
>
>
> 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
John Resig
--John
Dean Landolt
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
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
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
(equal is A === B, equiv is deep recursive equivalence).
--John
Chris Zumbrunn
>>> 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
> 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
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
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
John Resig
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
<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
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 ;-)