Lately, I’ve had language design on the brain. In short, I’m working to make Selenium tests Turing complete. Right now, the Selenium Core engine can parse simple command/key-word tests. No looping or conditional logic is provided, natively, out of the box in Selenium Core without using a user extension, like flowControl. Not that it’s a bad thing, this “limitation” is also considered newbie-friendly simplicity by many users of Selenium. (Here, I’m talking about the in-browser core of Selenium, you can get all kinds of Turing complete testing goodness using Selenium Remote Control on the server side with Java, C#, Ruby, Python, or Perl.)

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!