[Project_owners] casper code in cvs
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.
> 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,
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.
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
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
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
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
More information about the Project_owners