People still do that?! :-) No wonder “testers” get such a bad rap. Their mission is literally impossible.

Update: Thank you, Internets! Codepad.org is the answer. (Though UtilityMill.com looks similar, too.) Here’s the original thread on reddit that I was looking for, too.

With representatives from all the major Selenium projects on hand to present ideas, discuss the future of Selenium and answer audience questions, the Selenium Open Evening is an opportunity to get involved in the future of the project. With Selenium developers from as far apart as London, Tokyo and the US and Lightning Talks on related subjects, this is a great way to meet Selenium users and meet some of the other brightest minds in web testing and Agile development!

And here are the important event details:

Oh, and did I mention free food? And I’ll be signing autographs, too! :-)

If you’ll be in the Silicon Valley on Monday and love or hate all things Selenium, please sign-up now!

Amen! (And when I do have to work with code on the JVM, it’s via Rhino or Jython.) I don’t know how much I’ll use Arc in the future, but I already like its attitude.

Well, since last I posted… (~10 months!) I’ve been pretty busy. I started at Google eight months ago on March 5th, and so far it’s been great.

In April, I finally got to meet-up with several members of the core Selenium development team, specifically, Patrick Lightbody, Dan Fabulich, Nelson Sproul, and Paul Hammant. Paul and I go way back… See, I started Selenium Core, but he started Driven-now-known-as-Remote-Control. And RC is the flavor most heavily used at Google, so I owe all my future earnings to him, or so he thinks!

In May, I attended CITCON North America in Dallas, and led an informal talk on “The One True Programming Language for Writing Tests” (Slightly tongue-in-cheek, I was hoping for a good Python-vs-Ruby fist fight — I’ve missed those since leaving ThoughtWorks. :-)

In June, a “Short Cut” on Selenium was finally published. Many thanks to the hard work of Titus Brown, Grig Gheorghiu (co-authors) and Mike Loukides (our editor). Titus, Grig, and I are on the hook to write a few more of those, so stay tuned.

Hmmm… what else? I was interviewed on the Google Testing Blog in September. And I made a few presentations, once at the Google Developer Day back in May, and twice at the Google Test Automation Conference (GTAC) in September.

GTAC was especially fun. Jennifer Bevan and I publicly announced the “Selenium Farm” — work Google has been doing to improve and build upon Selenium RC, specifically making a multiplexed “farm” of many, many Windows, Linux, and Mac machines for teams, like Gmail and Docs to run their tests against. Selenium has become a standard (but not the only, of course) web testing tool for many high profile Google Apps. Gmail, for example, was able to bring their test time down from 40 minutes to 4 minutes by using the Selenium Farm. Cool! So, if you ever find a bug in Gmail, be sure to file a Selenium test for it for faster service. :-) As it turns out, though Google’s Selenium Farm has not been open sourced, yet… But a few crafty ThoughtWorkers saw the YouTube movie of our talk and started to work on a clean room implementation… A month later, the “Selenium Grid” is open sourced and available now! It’s slightly different than Google’s internal farm, but the high-level concepts are the same. I look forward to continuing the work I outlined in my GTAC presentation (this time with the open Selenium Grid) and use dozens of machines on Amazon’s EC2 cloud to bring down Selenium’s own build time down from the current 25 minutes to something more manageable in the 2-4 minute range. (It’ll also be nice to have a shareable Selenium grid client on EC2 for anyone to use in their own web test builds.) Also at GTAC, I got to debate Simon Stewart (also a former ThoughtWorker, and now Googler) on the topic of “Selenium vs WebDriver — the Steel Cage Knife Fight“. (If you want a chuckle, watch the last 30 seconds or so of that one.)

And lately, I started a “Makers” (as in “Make magazine” Makers) group at Google. For our first project, we’re working on something which will sound quite familiar to many agile teams. As you’d hope and expect, agile and testing are big here… and of course, every agile team needs to have some kind of cool, highly visible gadget to show off their build status. To that end, I’m working to put together some Do-it-yourself kits based on the Arduino board. The best example of this is explained in Arduino tutorial #3 at ladyada.net. In the spirit of Google’s roots, I’m sure there will be a few Lego blocks in there, too.

On that note, it just so happens that Google is a huge fan of Selenium for browser testing their web applications. According to veteran Googler Goranka Bjedov, “Google projects use open source tools, and Selenium in particular for their testing projects… Selenium is well regarded and people who use it are very happy with it.” Hey… I’m happy they’re happy!

It has been fun working with so many prolific and talented open source coders at ThoughtWorks over the years, and I look forward to being equally amazed by my fellow co-workers at Google. Well, at least until a position at NASA or Lego opens up. :-)

The recent security hole in Rails is interesting, not because there was a security hole, but because it looks like there were no (or, at least, not well-known) policies in place on how urgent information gets communicated and exactly what the expectation is for how far back the Rails Core team will provide security patches.

So to jump start my web framework evaluation checklist, I’m adding “What’s your policy on how you deal with security holes” to the top of the list. Django is pretty up-front and clear with their stated policy. Importantly, they explicitly state they will support patches for the current release at that time and the two previous releases. I’m still a little fuzzy on how much time is covered by “a current + 2 previous releases” policy. And I’m also a little fuzzy on exactly where I should look to be notified about such an event. But already, Django’s explicit policy is better than Rails implicit policy of “upgrade now, cause you should have been keeping up-to-date anyway.” Given the recent announcement of Rails shipping with Mac OS X - 10.5 (Leopard), how security issues are dealt with and disseminated becomes even more important to get right.

Many open source projects have low-volume, read-only mailing lists explicitly set-up for these kind of announcements. Granted, security ain’t easy and there is much debate on how to do it right. But if you’re a would-be Python web framework author, seriously consider how you’re going to deal with security vulnerabilties when you go-live.

On that note, help me flesh out my web framework evaluation checklist! What question would you add? And don’t say: “But does it scale?” :-)

I’ve had early success integrating Brendan Eich’s excellent Narcissus JavaScript engine into Selenium. Narcissus is pretty darn useful. It is a living breathing JavaScript interpreter for the browser. Now why would I need to use a JavaScript interpreter written in JavaScript to make Selenium Turing complete? In short– blocking code. In “Plain Old JavaScript”, you can’t easily tell the browser to pause the execution of JavaScript code while the browser loads a new page, then continue on with the rest of the script after page load. Sure, I can do some of this with Ajax or iframes, but the amount of boilerplate event listener code involved is quite ugly, and gets in the way of writing simple functional tests for web apps, which is the whole point of Selenium’s existence. It looks like the Narrative JavaScript project was created for this same reason, and it also (!) uses the Narcissus engine to work its magic. The difference here in what I’m doing vs what Narrative JS is doing is that my code doesn’t require a server-side compilation step. “Selenium JavaScript” is all done in the browser.

I’ve also dabbled with extending Narcissus and reimplementing my favorite language of all time– HyperTalk– in JavaScript as a syntactically sugar sweet “super-set” of JavaScript, so I’ll have a ‘native-in-the-browser’ testing language for Selenium (a ‘DSL for testing’, if you will), with no server-side dependencies (like Ruby, Java, Python, etc.). But this is slower going — getting HyperTalk parsing rules right and catching all the corner cases can be tricky. So just shipping plain old JavaScript support for the Selenium Core is the pragmatic thing to release for the moment. Even more pragmatically, with Plain Old JavaScript support in Selenium Core tests, it’ll be rather straight forward to port the Watir API to Selenium JavaScript for in-browser tests. I hope this raises a few eyebrows and generates some smiles with the Watir developers. :-)

On a side note, I’ve found A Pattern Language for Language Implementation (PDF) and the Little Languages blog incredibly useful as I grapple with the issues of language design and parsing techniques. At ThoughtWorks these days, writing DSLs in Ruby is all the rage. And with good reason, Ruby is very useful for prototyping your own little language. A few years ago, everyone was talking about design patterns. So design patterns for DSLs?! Man, I can’t imagine the cocktail conversations this is going to generate!

Dave Hoover wrote:

Not everyone hates JavaScript. After digging deeply into (Chicago resident) Sam Stephenson’s wonderful Prototype framework, extending it, and using it extensively, I can honestly say I enjoy working with JavaScript.

I came to a similar point in the development of Selenium. I hated JavaScript enough because of browser compatibility issues to write a testing tool to fix it. But at the same time, I liked JavaScript enough because it let me do spiffy things in the client. Alas, I decided to write a testing tool… Sam took a different path and wrote a code library, instead. But the motivation was probably the same.

To kinda hate something at first, but then grow to love it… I believe it’s called “Stockholm Syndrome“.

I agree when Dave said, “At least for now, I’d rather deal with JavaScript directly than have it generated for me by another language.” But I don’t claim that dealing directly with JavaScript is right or necessary for everyone. For example, Python, Ruby, and Perl are really written in C under the hood. But only a handful of people in the world really need to know C. I’m happy I can go years without having to look at any C code whatsoever. I suspect most of the world feels the same way about JavaScript. Guido and Matz are to C as Sam Stephenson is to JavaScript. They are all-stars because they liked C/JavaScript enough to be productive in it, but also hated it enough to write a more productive higher level tool so the rest of the world wouldn’t have to do the same.

However, when you write to the C platform, everyone can talk to you with ease. For example, there have been lots of ‘mini’ SQL database engines implemented for every language. Gadfly is the one I know about for Python. HSQL for Java. But SQLite is becoming quite popular across all languages because it is “100% Pure C”. So support and docs get better because a larger community of developers can make use of the code. Another example– YAML libraries…. Because _why wrote Syck as a C library instead of Pure Ruby, I get to use his code in Python quite easily. C gets you language binding to all the higher languages quite cheaply.

In a similar fashion, because Sam’s Prototype library is 100% JavaScript, it’s now used by PHP, Ruby, Perl, Python, Java, and .Net shops. And that’s the best empirical argument I can think of that JavaScript is the new C.

I imagine the source document will be HTML with a scent of ReStructuredText and a dash of Doctest. The intention is that the “doctest” code is written in JavaScript, interpreted and executed by the Selenium engine on the fly inside the browser.

----- begin 'spot test' source code ----------

========================
See.Spot.Login.to.Django
========================

To modify data in Django, you'll need to login to the 
administrative application with your username and 
password. For the purposes of this demonstration, 
I'll assume you are a dog and that your name is 'Spot'.

First, please navigate to the login page.

  >>> see.spot.open.the.url ('http://localhost:8080/admin')


You should now see a page with a form asking for 
username and password. 

  >>> var username = see.spot.get ('username')
  >>> var password = see.spot.get ('password')

  >>> see.spot.type(username).into.the.field.id ('username')
  >>> see.spot.type(password).into.the.field.id ('password')
  >>> see.spot.click.the.button.where ('id', 'submit')


Verify that you're now logged in and that you see 
the main administrative dashboard.

  >>> see.spot.verify.page.text.containts ('Welcome, Spot')
  >>> see.spot.verify.existence.of.link ('text', 'Log out')


==========================
See.Spot.Log.out.of.Django
==========================

When you're done editing data in Django, it's good 
practice to log out. Logging out will expire your session 
cookie and prevent other people from using your login 
credentials with the same computer and browser.

  >>> see.spot.click.the.link.where ('id', 'logout')
  >>> see.spot.verify.page.text.contains ('Thanks')
  >>> see.spot.verify.exisitence.of.link ('text', 'Log in again')


You are now logged out! Good boy, Spot!  

----- end ----------------------------------