Re: [CommonJS] Recount on Unit Testing API (was: Vote: use QUnit API or Unit Testing/A)
Kris Kowal
and "assert" as in #2. We converge with QUnit on standard names for
assertions. Then, we proceed to standardize loaders so that we can do
module dependency injection. From there, we can build a CommonJS
system that uses module dependency injection to load QUnit DSL modules
that call into the layer 1 interface. We'll probably also eventually
standardize an API layer for connecting the test.run method to call
into a logging layer, e.g., back into QUnit.
With this proposal, we only need to agree on names for the assertion
module's methods. If this proposal is reasonable, please contribute
nominations for complete API's in the following form, and then we can
do run offs.
A (ok, equiv, notEquiv, equal, notEqual)
B (ok, eq, ne, is, isnt)
C (ok, eq, uneq, is, isnt)
Kris Kowal
Dean Landolt
A, B, C -- in that order.
Until, of course, someone proposes something else. This is gonna be hard to keep track of :/
Kris Kowal
> Until, of course, someone proposes something else. This is gonna be hard to
> keep track of :/
Yes, please hold off showing your hand until all nominations are in.
Dean Landolt
D (ok, equal notEqual, deepEqual, notDeepEqual), A, B, C
Kris Kowal
In positions:
1 is the plain assertion method
2 is the deep equivalence comparison method
3 is the opposite thereof
4 is the shallow equivalence comparison (==)
5 is the opposite thereof
6 is the shallow strict equivalence comparison (===)
7 is the opposite thereof
A (ok, equiv, notEquiv, equal, notEqual)
B (ok, eq, ne, is, isnt)
C (ok, eq, uneq, is, isnt)
D (ok, deepEqual, notDeepEqual, equal, notEqual, same, notSame)
Kris Kowal
John Resig
Dean, Ash, Hannes, Nathan, Kris, and I discussed this on IRC and
decided that the following was acceptable:
D (ok, equal notEqual, deepEqual, notDeepEqual)
equal/notEqual uses either == or === (to be decided)
deepEqual/notDeepEqual does a recursive comparison on the object properties.
--John
Kris Kowal
In positions:
1 is the plain assertion method
2 is the deep equivalence comparison method
3 is the opposite thereof
4 is the shallow equivalence comparison (either == or == to be decided later)
5 is the opposite thereof
A (ok, equiv, notEquiv, equal, notEqual)
B (ok, eq, ne, is, isnt)
C (ok, eq, uneq, is, isnt)
D (ok, deepEqual, notDeepEqual, equal, notEqual)
Kris Kowal
Kevin Dangoor
Go with D, which is the one John said that several folks were okay with already, stick mostly with the existing Unit_Testing/A proposal and eventually converge on a system that can readily handle both QUnit style tests and Unit Testing/A tests.
I would still like to get something into the proposal allowing failed assertions to log rather than throw an exception...
Kevin
--
Kevin Dangoor
work: http://labs.mozilla.com/
email: k...@blazingthings.com
blog: http://www.BlueSkyOnMars.com
Kris Kowal
>> D (ok, deepEqual, notDeepEqual, equal, notEqual)
> already, stick mostly with the existing Unit_Testing/A proposal and
> eventually converge on a system that can readily handle both QUnit style
> tests and Unit Testing/A tests.
Ok.
> I would still like to get something into the proposal allowing failed
> assertions to log rather than throw an exception...
I'll write some verbiage about that. Probably something like
exports.assertions = "log"; or by default "throw".
Kris Kowal
George Moschovitis
> B (ok, eq, ne, is, isnt)
> C (ok, eq, uneq, is, isnt)
> D (ok, deepEqual, notDeepEqual, equal, notEqual)
-g.