So unpack the Selenium Grid tar file and start er up. no problem.
Basic Java demos for Selenium Grid ran fine; nice. I always found it a compliment when folks said my stuff "just works." This griddage just works.
Since my dorky login failure spike is in Ruby, I decide to give the Ruby examples a whirl. This is where not knowing Ruby really hurt!
I started off by followed Ruby instructions from selenium-grid but I don't think the grid examples have been keeping up with changes in the Ruby world.
I found I had to
* change the yml configuration with paths to apps on my OS X machine
* to run the ruby tests add gem install rspec
* change the example/ruby/Rakefile to use rspec > then default 1.1.8
* gem install deep_test, modify path to pull it in, change Rakefile to >=
* find out that the spectask no longer exists, switch over to rspec/core/rake_task
* upgrade version requirement for selenium-client to >1.2.7
but eventually stopped - I don't know enough Ruby and Ruby culture to figure out what is going on with the un-updated dependencies. Something called Spec is / was in the middle of being converted to RSpec, or was converted, and something called deep_test is still deep_test_pre? or what? this is noising up my spike.
I realized that, tho, I can brute force the Ruby test by running multiple Ruby processes against the server, and have 4 registered RC processes. That should show how the Ruby jobs are doled out to the RC workers. Not very useful in a 'share the love' kinda way but it'll help me see what other kinks there.
It only takes a moment to open a mess of shells and script up some parallel testing against a local Sakai3 instance, fine, a login in 11 secs on average, and a one line URL change to send a mess of logins to sakai3.sakaiproject.org. Ohh Kay. About 18 seconds on average.
Next to distribute this run-kit to other machines around here and preform the test again. Works well, quite nice. I make a set of assumptions about the location of browsers on various machines which mostly work out.
Mostly in that this leads to an inadvertent creation of a 'headless' Firefox instance on remote machines. I'll have to describe that tomorrow - this may be useful. The central idea is that the user running an OS X Window Server process is the only one, other than root, who can launch new windows. Give it a whirl from your OS X command line. So when Selenium RC wants to launch a new Firefox it needs to be running as the user who is running the windowing system. Mostly. Sorta.
What I get is a non-window-displaying Firefox which still navigates Sakai3. cool; it runs the test a couple of seconds faster.