Yes, I misunderstood what you were aiming at.
The master branch at github was last updated 2010-02-18, the latest release
(2.2) was uploaded 2009-11-28. So it might be time for another review.
That hasn't changed, but I do not consider it a problem in itself. I have a
source code editor to view and edit the source if it turns out to be
erroneous. What I have a problem with is that the test site of JsUnit 2.2
is apparently not scrollable in Firefox (so I need full screen), but that
could be remedied.
There is a Stop button, so that appears to have changed in the meanwhile.
That actually sounds familiar. However, I do not recall useful stop
functionality.
It can only be as good as what the ECMAScript implementation provides. I
think they are doing not bad there. I could even reuse their approach in
providing a stack trace along with my exceptions.
That appears to have changed.
How do you propose that to be implemented?
wait and waitForCondition can each use setTimeout.
The test that fires oncomplete when all deferred segments are done and
to know when that happens, it subscribes to the "oncomplete" of each
segment.
This means that tests may complete out of order.
A test is part of a tree structure and has a testableList of deferred
segments (possibly 0 length). A deferred segment is also a Test and when
a deferred segment calls wait, then the deferred segment gets an item in
its testableList; it won't fire oncomplete until is not done.
TestRunner is the root node of the tree. TestRunner can have tests and
suites, but the caller doesn't actually have to create formal
structures, the caller can just add things to the TestRunner.
I explained a little recently in MessageID:
[email protected]
It's a little sloppy right now; I've got some rough spots in it.
Which alternatives to JsUnit are you recommending?
The most relevant I found at the time I was searching was YUI Test
I've run into too many problems with that. Starting with the author
takes a long time to fix bugs (1 year+). Getting free contributions
accepted to YUI requires you to sign legal documentation that I don't
want to sign.
I have had to patch many things in it, such as relatedTarget not working
properly. The source code shows the problems in code comments and the
author shows how he did not solve them.
/*
* Check to see if relatedTarget has been assigned. Firefox
* versions less than 2.0 don't allow it to be assigned via
* initMouseEvent() and the property is readonly after event
* creation, so in order to keep YAHOO.util.getRelatedTarget()
* working, assign to the IE proprietary toElement property
* for mouseout event and fromElement property for mouseover
* event.
*/
if (relatedTarget && !customEvent.relatedTarget){
if (type == "mouseout"){
customEvent.toElement = relatedTarget;
} else if (type == "mouseover"){
customEvent.fromElement = relatedTarget;
}
}
You can see the test function is tied to the code that is being tested.
The author's comment "in order to keep YAHOO.util.getRelatedTarget()
working, assign to the IE proprietary toElement property"
Mentioning problems to the author is a waste of time; he just either
ignores email or won't fix the bugs.
http://sourceforge.net/tracker/?func=detail&atid=836476&aid=1889966&group_id=165715
Got fixed. Other bugs that didn't were the event simulation req for
Apple Touch Events. I submitted a patch and the reply I got was "please
sign these legal documents so we can use your code for free.". Wow, what
a great way to show appreciation. No thanks, I'll just patch where I
need to and forget about submitting bugs in the future.
The debugging issues in YUI Test are painful. Each dispatched event
calls a very long function -- around one hundred statements or so.
This is a problem when you want to step from dispatching the event
through to the callback.
Given an element "myTargetObject" with a mousedown event handler, the
following test would dispatch that event and then afterwords, the
condition of `a` could be checked. Synth events are not always the same,
so sometimes you want to step into with debugger to see what actually
happens. For example:
testMyEvent : function() {
debugger; // Click 'step over' 47 times after this
Action.mousedown(myTargetObject);
Assert.isTrue(myTargetObject.a, msg);
}
After explaining to the author how to refactor that, he brushed off the
possibility and claimed that the functions must be long and then ignored
all subsequent emails. So again, I wasted time to try to help but got no
appreciation for it. I get the sense that it is more of a public image
type of thing with the author.
I also found that focus and blur events were not implemented, but needed
to be for some cases; that is: Where `focus()` on particular object
would not work for that given case. I can't remember why, maybe it had
to do with onfocusin -- I forgot. I added support for focus and blur
events (which also fire onfocusin and onfocusout).
Other frustrations are the inability to rerun just one particular test
function.
In 2007, I found that YUI Test was attractive. The limitations have
become so burdensome that it is time to move on.
Garrett
