Mark Redar at CDL has some selenium tests for calisphere.org/mapped but they are not automatically run
I've been wanting to play around with selenium grid on EC2 but never had the time / real reason to -- but if it is as advertised it might speed up running the tests by executing them in parallel http://selenium-grid.seleniumhq.org/ http://selenium-grid.seleniumhq.org/run_the_demo_on_ec2.html -- Brian On Jan 12, 2011, at 8:45 AM, Demian Katz wrote: > For what it's worth, the VuFind community has recently been playing with > Selenium (not an especially new or exciting technology, I realize... and > probably one of the things you were thinking of for approach #1). The good > news is that it plays well with Hudson, and we have been able to get it to > successfully automatically test AJAXy code in Firefox as part of our > continuous integration process. The bad news is that it's incredibly slow -- > that successful test takes ten minutes to execute, and all it does is load > one web page and confirm that a lightbox opens when a button is clicked. I > wouldn't realistically expect this sort of thing to be FAST, but the current > performance we are experiencing stretches belief a bit -- we're still > investigating to see if we're doing something wrong that can be improved, but > the general consensus seems to be that Selenium is just really slow on > certain platforms. It's a shame, because I think we could potentially write > a very comprehensi! ve! > and powerful test suite with Selenium... but tests are significantly less > valuable if they can't give you reasonably quick feedback while you're in the > midst of coding! > > In any case, I'm happy to share my limited experience with Selenium if it's > of any use (some VuFind-specific notes are here: > http://vufind.org/wiki/unit_tests#selenium and more can probably be gleaned > by looking at VuFind's test-related configuration and scripts). I'd also be > very interested to hear if anyone has overcome the speed problems (which I've > encountered under both RedHat and Ubuntu, possibly related to using a virtual > frame buffer) or if there is a better, equivalent solution. > > - Demian > >> -----Original Message----- >> From: Code for Libraries [mailto:code4...@listserv.nd.edu] On Behalf Of >> Jonathan Rochkind >> Sent: Wednesday, January 12, 2011 11:32 AM >> To: CODE4LIB@LISTSERV.ND.EDU >> Subject: Re: [CODE4LIB] javascript testing? >> >> As far as I can tell, while there are several, there are none that are >> actually Just Work good. It seems to be an area still in flux, people >> coming up with an open source way to do that that is reliable and easy >> to use and just works. >> >> The main division in current approaches seems to be between: 1) Trying >> to automate _actual browsers_ so you know you've tested it in the real >> browsers you care about (the headaches of this are obvious, but people >> are doing it!), and 2) Using a headless javascript browser that can be >> run right on the server, to test general javascriptyness but without >> testing idiosyncracies of particular browsers (I would lean towards >> this >> one myself, I'm willing to give up what it gives up for something that >> works a lot simpler with less headaches). >> >> Jonathan >> >> On 1/11/2011 7:21 PM, Bess Sadler wrote: >>> Can anyone recommend a javascript testing framework? At Stanford, we >> know we need to test the js portions of our applications, but we >> haven't settled on a tool for that yet. I've heard good things about >> celerity (http://celerity.rubyforge.org/) but I believe it only works >> with jruby, which has been a barrier to getting started with it so far. >> Anyone have other tools to suggest? Is anyone doing javascript testing >> in a way they like? Feel like sharing? >>> >>> Thanks! >>> >>> Bess >>>
