Posted on Saturday, 6th September 2008 by charpi

In a previous post, I was arguing that selenium-rc missed an erlang library, so I did it.

The communication protocol is very simple, so it was very easy to implement it with erlang. At the time of the writing the only things I didn’t tested (and implemented) are unicode support and exponential number in response.
I know that the number of code line isn’t a ‘real’ good metric, but all the code for this binding is about 400 lines of code (code, unit test and acceptance test). I think that it’s quite small…

All selenium server commands are described in a xml files, so OpenQA used a XSL spreadsheet to generate all client bindings. For my erlang version, I didn’t’ use this strategy for 2 reasons. I only want to have erlang code. XSL is a bit complex so I tried erlang first but it’s not the main reason.

Functional programming offers us another way of thinking so I tried to explore it a little more. For example, classic client bindings have a function (or method) for each selenium command. I don’t think that it’s useful to have such a list, we can use simple erlang atoms to choose the command to send. With my strategy I only need one function
to be able to handle all selenium commands. By extension, why limit the command that an user could send ? The protocol can be used with any kind of test server.

Update: you can find all informations about this library on the erl_selenium trac page.

Tags: ,
Posted in Uncategorized | Comments (2,740)

Comments are closed.