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 _______________________________________________ Project_owners mailing list [email protected] http://mozdev.org/mailman/listinfo/project_owners
