Unit Testing 1.0 Candidate
Kris Kowal
names are (ok, equal, notEqual, deepEqual, notDeepEqual, strictEqual,
notStrictEqual). The argument order is (actual, expected,
message_opt).
http://wiki.commonjs.org/index.php?title=Unit_Testing/A&action=history
This would defer several features for future versions:
1.) In the very near term, support for logged assertions. I think we
can do this with the addition of an "assert.Log()" type that would
host the same assertion API but would call user-defined ".pass()",
".fail()" internally. It would also provide ".expect(n)" and other
facilities. Having thought about this for a minute, I think that
making a proposal for this would invoke a lot of new debate so I want
to postpone it (only a little!)
2.) Async tests.
3.) After we have a standard for module dependency-injection (like
"require.loader.load(id)({injection})") as an amendment to the
CommonJS Modules specification, a specification for the QUnit API as a
CommonJS DSL. We can implement this in the near term and standardize
in due course.
4.) Stuff I'm forgetting at the moment, but no doubt will be brought up.
Kris Kowal
Tom Robinson
Though rather than recommending custom assert methods throw an
AssertionError why don't they call assert.fail() or assert.pass(),
which will either throw an AssertionError or communicate the pass/fail
to the runner directly for logging. This way they'll be compatible
with both the "fail fast" and "logging" style test runners.
John Resig
throw an exception if it's explicitly included in a exports.testFoo
function. If the spec is changed in this way then QUnit can support
both styles of coding simultaneously
run({ testFoo: ... }) and
test("foo", ...)
(where the first one would throw an exception on fail and the second wouldn't)
Also, It should probably specify that the prefixed test methods
actually contain some characters after the fact - that way just a {
test: function(){} ) is ignored (and, more appropriately, it's
possible to do exports.test and not have it be considered a testing
method).
--John
Kris Kowal
> Very close - one extra thing that I realized: assert() should only
> throw an exception if it's explicitly included in a exports.testFoo
> function. If the spec is changed in this way then QUnit can support
> both styles of coding simultaneously
>
> run({ testFoo: ... }) and
> test("foo", ...)
> (where the first one would throw an exception on fail and the second wouldn't)
I think we'd ultimately like to support early-fail and fail-log
regardless of whether it's in the DSL or raw. It seems likely to me
that making this possible in the QUnit DSL would involve having the
assertion methods proxy their calls to an object on a stack somewhere
behind the scenes, so one test could push a logger on the assert API
stack, and another would put the raw "assert" module object on the
stack for the early-fail behavior.
In any case, I think this spec is a good first cut. Perhaps I ought
to start hacking QUnit to show you what I have in mind. Give me a bit
since github doesn't appear to be able to fork at the moment.
> Also, It should probably specify that the prefixed test methods
> actually contain some characters after the fact - that way just a {
> test: function(){} ) is ignored (and, more appropriately, it's
> possible to do exports.test and not have it be considered a testing
> method).
Ok http://wiki.commonjs.org/index.php?title=Unit_Testing%2FA&diff=1686&oldid=1685
Kris Kowal
Ash Berlin
+1
Though rather than recommending custom assert methods throw an
AssertionError why don't they call assert.fail() or assert.pass(),
which will either throw an AssertionError or communicate the pass/fail
to the runner directly for logging. This way they'll be compatible
with both the "fail fast" and "logging" style test runners.
George Moschovitis
> names are (ok, equal, notEqual, deepEqual, notDeepEqual, strictEqual,
> notStrictEqual). The argument order is (actual, expected,
> message_opt).
-g.
Chris Zumbrunn
>
> I'm proposing the current wiki version for a 1.0 ratification. The
> names are (ok, equal, notEqual, deepEqual, notDeepEqual, strictEqual,
> notStrictEqual). The argument order is (actual, expected,
> message_opt).
>
> http://wiki.commonjs.org/index.php?title=Unit_Testing/A&action=history
+1
Hannes Wallnoefer
> I'm proposing the current wiki version for a 1.0 ratification. The
> names are (ok, equal, notEqual, deepEqual, notDeepEqual, strictEqual,
> notStrictEqual). The argument order is (actual, expected,
> message_opt).
>
> http://wiki.commonjs.org/index.php?title=Unit_Testing/A&action=history
Hannes
Kevin Dangoor
I'm proposing the current wiki version for a 1.0 ratification. The
names are (ok, equal, notEqual, deepEqual, notDeepEqual, strictEqual,
notStrictEqual). The argument order is (actual, expected,
message_opt).
http://wiki.commonjs.org/index.php?title=Unit_Testing/A&action=history
+1
--
Kevin Dangoor
work: http://labs.mozilla.com/
email: k...@blazingthings.com
blog: http://www.BlueSkyOnMars.com
Ates Goral
> names are (ok, equal, notEqual, deepEqual, notDeepEqual, strictEqual,
> notStrictEqual). The argument order is (actual, expected,
> message_opt).
>
> http://wiki.commonjs.org/index.php?title=Unit_Testing/A&action=history
+1
Davey Waterson
Georgiy Ivankin
For example, expect.js almost always treats nodes as deep-equal. QUnit doesn't, but only because it uses deep for-in without hasOwnProperty check to iterate through objects.
The options to properly check deep equality of 2 nodes that I can see are:
- use deep for-in check
- use isEqualNode, however I'm not sure about browser support
Of course this is applicable only to browser environment and as such maybe is not the case for this spec at all. But even then, many libs use it to implement testing algorithms and imho there should at least be a note about this issue.
Please correct me if I'm wrong or if it's not the right place for feedback: as a spec contributor I really am a novice.
вторник, 13 октября 2009 г., 3:24:15 UTC+4 пользователь Kris Kowal написал: