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.
> 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.
3. Use doctest <https://developer.mozilla.org/en/New_in_Rhino_1.7R2#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.
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)
> 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.
> 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
> just CommonJS compliance tests, though.
On Fri, Oct 9, 2009 at 10: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'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 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
On Fri, Oct 9, 2009 at 11:58 AM, Kris Zyp <kris...@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...
On Fri, Oct 9, 2009 at 11:44 AM, John Resig <jere...@gmail.com> wrote:
> I vote for #1.
> --John
> On Fri, Oct 9, 2009 at 10: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'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.
>> On Fri, Oct 9, 2009 at 10: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'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.
On Fri, Oct 9, 2009 at 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'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.
> On Fri, Oct 9, 2009 at 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'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)
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.
On Fri, Oct 9, 2009 at 1:33 PM, John Resig <jere...@gmail.com> wrote:
> I should mention that I'm fine with #1 with the stipulation, as well
> (equal is A === B, equiv is deep recursive equivalence).
> --John
> On Fri, Oct 9, 2009 at 11:44 AM, John Resig <jere...@gmail.com> wrote:
> > I vote for #1.
> > --John
> > On Fri, Oct 9, 2009 at 10: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'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.
> 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.
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.
<thatcher.christop...@gmail.com> wrote:
> +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
> On Fri, Oct 9, 2009 at 1:33 PM, John Resig <jere...@gmail.com> wrote:
>> I should mention that I'm fine with #1 with the stipulation, as well
>> (equal is A === B, equiv is deep recursive equivalence).
>> --John
>> On Fri, Oct 9, 2009 at 11:44 AM, John Resig <jere...@gmail.com> wrote:
>> > I vote for #1.
>> > --John
>> > On Fri, Oct 9, 2009 at 10: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'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.
<thatcher.christop...@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.
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 ;-)
