Learning New Things

Today was an average afternoon – taking way too long to accomplish a seemingly trivial task, but looking up and learning a bunch of new things along the way. It seems there should be a better/easier (almost automatic, transparent) way to track the sources (links/pages), process (things tried) and results (code fragments)….

The basic goal in this case was to automate some execution of some javascript on a page. Because execution of the script caused a page load, it wasn’t a matter of writing the calls into the console. The faster and easier way would have been to write a Greasemonkey or Chrome Extension script (because there were timing issues, the script would have to write a time-based state file on actions), however, I figured I would try to see what kind of options were available with a control-script oriented model, as having that handy would be more generally useful in the future (more and more, straight mechanize is less useful as more JS proliferates).

Before getting started, I had to strip out just the lines that I wanted. I always forget how to do it, but that was a simple vim command lookup.

I looked at Selenium and Selenium RC, which probably would have worked fine (but that I didn’t use because I didn’t want to install extensions and the RC docs weren’t directly linked, but would have probably saved me time in the end).

Instead I decided to try out Watir (cross-platform, cross-browser, and my Ruby is rusty so this was a good excuse). I started out with SafariWatir, however, after a bit of poking, came up with a dead end on executing JavaScript. There’s a scripter object, but even after getting access to it via monkey-patching (did I mention my Ruby-fu sucks?), I was still getting errors and there wasn’t much help In general.

Instead of slogging through a potentially losing battle, I decided to jump ship to FireWatir. FireWatir uses JSSh, which communicates directly via JavaScript to Firefox, so it seemed like it might be a surer thing. My Firefox profiles were corrupted from my last system transfer, so there was a bit of messing with the profile folder until I gave up and started a new, but after that it seemed like I was home free.

Except, that when running js_eval, it turns out the scope that JSSh puts you in, isn’t in the document DOM, but rather the browser’s XUL DOM. For whatever reason, I couldn’t find a reference for even with the direct object type refereces (i.e. getWindows and getBrowser return ChromeWindow objects, which just don’t seem to have docs. Introspection via domDump() or inspect() just returned a huge amount of stuff to go through). Luckily, while searching, one of the results that turned up was a StackOverflow question on firewatir + jQuery which answered the question – ChromeWindow.content gets you into the HTMLDocument DOM. I’m a bit mystified why this isn’t in the firewatir or JSSh docs, as this seems to be one of the most common things that people would want to do, but well, that is the life of the developer…

  • bertrandom

    Selenium and Selenium RC are actually really good if you can get past the fact that the documentation is all over the place. The Firefox extension, Selenium IDE:


    is key because you can record entire workflows, which you can export to a variety of formats and tweak as needed. This makes writing functional tests really easy because you can hit Record, and manually run through a testable action, for example:

    Login as a test account
    Open the URL for a photo
    Fave the photo
    Sign out of the account
    Open the test accounts favorites
    Check for the existence of the photo in the DOM

    Then you could export this to PHP and add stuff like checking the database if that favorite row actually exists, etc. The other cool thing about Selenium is that you can have Selenium RC running on different machines, like a Windows box (or a virtual machine running windows), and it can run through the same tests on a variety of different browsers, like IE7 or Chrome for Windows, etc.

  • lhl

    Yeah, I remember Selenium worked well in Firefox when we used it at BSD. I was initially turned off by RC because when you click on the doc link for the RC doc it redirects you to the TOC for the main doc. Once you click in, you have to go through pages just to get basic info and finding how to execute JavaScript is pretty deep in there, but there. The documentation is actually quite extensive, much better than Waitr – I'm just predisposed against docs that don't respect developers' time by starting w/ like sample code that gets you started/shows you what it can do right off the bat – it shows a real philosophical difference, and usually is a good indicator for something that will be more trouble than it's worth.