Jason R Huggins wrote:
The biggest reason is that JsUnit looked like it could easily handle the
testing of single, discreet web pages... But it couldn't handle (and is
not meant to handle) the transitions between pages (e.g.: enter data in
a form, click a button, wait for new page, then proceed with the next
command)-- aka "login to logout" style tests.
While I suppose, in a sense, you're right, I think this is an odd way of
putting that point. For example, nobody ever says of JUnit that it can't
handle database stuff... and why should it? It's just providing a
bare-bones framework within which you can write any code you want. If you
want to test a database, write code to manage your database. JUnit is
just the *test* framework... it's not really supposed to "handle" anything
at all except for keeping track of your results.
So, to put your point another way, JsUnit *can* handle transitions between
pages: you just have to code an entire BrowserBot on top of JsUnit to make
it do that. (Which, thankfully, you already have.)
Also, the JsUnit docs say that you could make the hidden iframe visible
(like Selenium does)-- but only in IE.
Can't you just pop open a new window and do all your work in there?
BTW, did I mention that JsUnit+BrowserBot can handle framed applications,
no sweat?
And I like the "stepping debugger" aspect of Selenium's interface for
slowly stepping through tests to find out where and how a test failed. I
didn't see how to easily do that with JsUnit.
I just use Venkman. :-) I'm also told that you can use VS.NET to debug
JavaScript running in IE, though I haven't tried it myself.
Lastly, at the time, I was enamored with Ward's FIT Framework, and its
promise of "tests that people can read".
This is certainly a good point. One thing that I might wind up doing is
writing a translating parser from HTML-table Selenese into JsUnit tests,
just to make sure nothing was lost in the transition. I note that it
would have been impossible to write the translation in the opposite
direction.
One thing that I think can't be overlooked is the value of *stacktraces*
in J(s)Unit. Stacktraces make debugging substantially easier, in my
experience; asynchronous event callbacks tend to undermine the value of
these stacktraces (throwing away historical information), which is why I
investigated synchronous sleep.
This is an area that we do have working in Selenium. Although there is a
proposal from Bret Pettichord to change or improve how we do it in
Selenium.
Yup, I'm following that discussion.
Getting the browser to wait is damn tricky business. Read these two posts
from some "color commentary" on the subject.
http://www.josephmoore.net/2005/11/non-cpu-intensive-javascript-wait-loop.html
http://www.josephmoore.net/2005/11/using-seleniums-waitforvalue.html
Recursive setTimeout() won't suffice in the middle of a JsUnit method, of
course, but it's definitely a good thing to have around.
Yes, requiring a Java applet or ActiveX control to implement a wait
command is very kludgey. :-)
I'll be the first to admit it, but frankly, it's still my favorite
solution. Writing your code in a synchronous way makes it easier to read,
write, understand, and debug (using Venkman). [Imagine if we replaced all
the setTimeout() stuff in Selenium itself with synchronous sleep()
calls...?]
Because of the timing/event issues... I'm thinking it might be easier to
run pure JavaScript tests in Selenium's TestRunner test harness than
running Selenium tests in JsUnit's TestRunner.
Would it change your mind if I translated the entire Selenium test suite
into JsUnit tests? ;-)
-Dan
-unless you love someone-
-nothing else makes any sense-
e.e. cummings
_______________________________________________
Selenium-users mailing list
Selenium-users@lists.public.thoughtworks.org
http://lists.public.thoughtworks.org/mailman/listinfo/selenium-users
