Unit Testing 1.0 Candidate

165 views
Skip to first unread message

Kris Kowal

unread,
Oct 12, 2009, 7:24:15 PM10/12/09
to comm...@googlegroups.com
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

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

unread,
Oct 12, 2009, 7:43:32 PM10/12/09
to comm...@googlegroups.com
+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.

John Resig

unread,
Oct 12, 2009, 11:05:12 PM10/12/09
to comm...@googlegroups.com
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)

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

unread,
Oct 13, 2009, 12:32:55 AM10/13/09
to comm...@googlegroups.com
On Mon, Oct 12, 2009 at 8:05 PM, John Resig <jer...@gmail.com> wrote:
> 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

unread,
Oct 13, 2009, 4:02:32 AM10/13/09
to comm...@googlegroups.com

On 13 Oct 2009, at 00:43, Tom Robinson wrote:


+1

Ditto. Looks good to me


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.


"pass" or "fail" would then need to take all the other arguments (not a problem, just saying.) Also depending on the type of logging, the method might want to format the display in a different manner, for example if HMTL output, a eqOrDiff test might want to display an the output formatted with html to make the diff more obvious.

In short - there is more to 'logging' in tests than just yes or no - diagnostic info is often a huge timesaver in working out why the test failed – and it would be nice if the diag can be closely tied to the failure. (perl's prove messes this up sometimes and you end up with the diag somewhere else in the TAP stream, and its odd every time it happens.)

-ash

George Moschovitis

unread,
Oct 13, 2009, 6:43:33 AM10/13/09
to CommonJS
> 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).

+1.

-g.

Chris Zumbrunn

unread,
Oct 13, 2009, 7:46:35 AM10/13/09
to comm...@googlegroups.com
On Tue, Oct 13, 2009 at 01:24, Kris Kowal <cowber...@gmail.com> wrote:
>
> 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

unread,
Oct 15, 2009, 6:52:27 PM10/15/09
to CommonJS
On Oct 13, 1:24 am, Kris Kowal <cowbertvon...@gmail.com> wrote:
> 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

Kevin Dangoor

unread,
Oct 16, 2009, 8:26:48 AM10/16/09
to comm...@googlegroups.com
On Mon, Oct 12, 2009 at 7:24 PM, Kris Kowal <cowber...@gmail.com> wrote:

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

unread,
Oct 22, 2009, 3:18:23 PM10/22/09
to comm...@googlegroups.com
On Mon, Oct 12, 2009 at 7:24 PM, Kris Kowal <cowber...@gmail.com> wrote:
>
> 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

Davey Waterson

unread,
Oct 24, 2009, 6:06:52 PM10/24/09
to comm...@googlegroups.com
+1

Georgiy Ivankin

unread,
Nov 8, 2012, 9:08:28 AM11/8/12
to comm...@googlegroups.com
The current spec seems to be incomplete in part 7 (deep equality). Currently in the algorithm there is no special case for comparing DOM nodes. And many popular implementations that follow the spec precisely fail to compare them correctly.

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 написал:
Reply all
Reply to author
Forward
0 new messages