Consider this test. Lets assume that a#mylink does not exist in the page. (so the test should fail)

1. test("funcunit test case", function(){
2.       ok(S('a#mylink').visible(), 'link is visible');
   
3. });

Expected result:  One failed assertion
Actual result: One successful assertion and one failed assertion   ?!

qUnit output:

"link is visible" - successful assertion
"waiting for size on a#mylink:visible" - failed assertion




I'm not sure that this behavior is desired? I only setup one assertion in this test case. So why should FuncUnit create two assertions in the output of qUnit?

So this doesn't make much sense to me. The "link is visible" assertion failed - so what is the point of flagging it as successful in the qUnit output?

Perhaps if the qUnit output actually tied both of those messages together in some way it may make sense for a single assertion to produce two output messages in qUnit.

Currently if there are multiple assertions in a test case that fail, then it is even harder to read and understand the messages that are being produced. I.e. some messages claim to be successful (when they're not) and others are error messages relating to what went wrong - but there is no way to easily see which error messages relate to which failed assertions.



Also, another problem I just thought of:

Because FuncUnit is creating it's own "error" assertions in the output of qUnit, it is now impossible to reliably use the expect() function in qUnit.  I.e. how can we tell qUnit how many assertions to expect, if FuncUnit is able to add additional assertions ? (thus, the total will not match what was defined in expect();  )


Let me know if I've overlooked something here.