[Project_owners] casper code in cvs

Shane Caraveo shanec at ActiveState.com
Wed Apr 25 15:33:55 PDT 2007


btw, casper requires jslib at this time.

Myk Melez wrote:
> Shane Caraveo wrote:
>> I haven't wrapped in into a xpi or provided a download, it's just in 
>> cvs.  if I wasn't sick and trying to get a release out this week, I'd 
>> put more effort into it but that'll have to wait.  I'm more interested 
>> to see if anyone see's any potential in using this.
>>   
> Shane,
> 
> Mozilla has been making a big push on testing for Gecko 1.9/Firefox 3, 
> including work on the newer Mochitest framework in addition to the older 
> reftest and xpcshell.

Yeah, if that had been started a year ago, casper wouldn't exist. :)  I 
would have just adopted what mozilla is doing.  given that, casper may 
do some things or use cases that are not supported by current methods 
mozilla is using.

> I'll shortly start working on tests for a couple of chunks of Firefox 
> functionality and am facing the decision of which framework to use, so 
> I'd be interested in hearing how casper compares to the other extant 
> frameworks and what tasks it's best suited for.

I cannot really give you a comparison against other frameworks, since I 
automatically did not consider any framework designed for 
web/html/js/browser environments.  I wanted a XUL App testing framework, 
not a javascript/website testing framework.  That pretty much left 
XULUnit at the time.  I used XULUnit as a starting point, you'll see 
that in the report dialog.  I dropped all the code from XULUnit after 
some point, because I had to deal with finishing tests after a 
window.settimeout call, and the XULUnit unittest classes were not 
capable of that.

Some of the reasons for writing something fresh...

* need to test a running GUI.  we currently do lots of manual testing, 
much of our app functionality is tied to UI events.  Also want to be 
able to test XBL at runtime.

* didn't want browser aware javascript code in a framework that was only 
going to be run on mozilla

* wanted a tighter coupling between the unittest structure and the 
behavior of the event system in mozilla.  The unittest classes in casper 
can be used "asynchronously", so you can test code that uses 
window.settimeout calls to complete something.  For example, many of our 
commands call a settimeout because we want menu's to dissapear before 
executing the command.

* need to replicate some internals of mozilla at the js level to get a 
relatively close reproduction for testing.  eg. keybindings are tricky 
to test because mozilla does magic with key events in c++.  You'll 
notice (in events.js, search for nsEventStateManager) that I replicate 
some of the mozilla event loop in javascript in order to provide a 
better replication of key events.  Our unit tests actually create key 
events that go through the chrome event handling system, resulting in 
window timeout calls, etc., before completion.  This is the closest I've 
been able to get to manual testing without manual testing.

* desired something that an "end user" (ie. non-Komodo-developer) could 
use to create a unittest to replicate bugs they encounter.  this is 
where the "recorder" comes in.  My inspiration behind this was Selenium 
recorder (fx extension).  It records events and produces a javascript 
unittest that plays them back.  it doesn't work all that well at this 
time for that use case, since you have to know pretty well what you are 
doing to choose the proper events to record.  If you choose the wrong 
events, or wrong combination of events, the playback doesn't work.


Some of the features:

* real GUI testing via emulated DOM events
* async js unittest classes
* event recorder that creates a unittest class to playback
* mozilla eventloop emulation
* designed for xul apps, not websites
* command line args for autostarting/shutdown of xul app GUI
* test files written in javascript as unit tests, not xml or some other 
format

I would say it's definitely an alpha.  There's plenty to be ironed out 
and "ease of use" is not where I want it to be.  I'm also not certain 
this is the best way to do things, but it's the best I've come up with 
so far.

Shane


More information about the Project_owners mailing list