Blogging Pubbitch

There are two reasons why a user may want to simulate keyboard entry when automating tests of a webapp:

1. To test keyboard shortcuts
2. To enter text into a form

The first of these typically involves testing that the various events that might be fired on the DOM ("keyup", "keypress", "keydown" and so on) are handled correctly. This generally means automating the input of letters that appear on the keyboard, perhaps chorded in some way with meta characters such as "shift". The important feature is that we need to ensure that the right DOM events are fired in the right order.

The second case is more interesting. Why would you push text into form fields? In danger of sounding like the sort of person who believes that the world is split into two types ("those who believe that the world is divided into two sorts of people and those who don't"), there are two possible reasons:

1. To test form completion and error checking
2. To test internationalization (aka: i18n, because it's a lot easier to spell)

Before going any further, it's probably reasonable to ask "why am I whittering on about automating keyboard entry?" It's because I want to get this right on WebDriver. We have a single API for this (WebElement.sendKeys) that we're attempting to shoe-horn both of these use-cases into, and I'm not quite sure how to handle it.

Rather than introduce a new API, I suspect that what we'll do is take a look to see what's being typed. If the text entry can be done directly with the current (hardware) keyboard, we'll attempt to do the full keyboard thing (including all the DOM events)

If, however, you attempt to start inputting Klingon, we're going to have to be a little smarter. In the ideal world, we'd "know" how your particular browser expected to receive this data, and jump through the large number of key presses that your multi-lingual input editor would make you do. This approach would probably entail a vast series of lookup tables, lots of experimentation and a careful eye to detail to get it right. More simply, we can push the entire multibyte character into the text field and pretend it all happened with a single key press.

Personally, I lean towards the simpler approach because in the case of multibyte input, we're probably going to be testing i18n. Also, I don't want to have to be the one who figures out the lookup tables....

I'd love to hear what you think, either in the comments of this blog post, or by joining the WebDriver mailing list, because I want to get this one right.