How come Ruby ?

The most interesting projects from my (and this blog posts) point of view are Watir and Ruby on Rails, the former from a testers point of view, the latter from web developers.

Good projects don’t just come from nowhere, either. The language itself is very elegant and enjoyable to use. Having a programming language that works for you instead of against you is going to leave more time for innovation and thinking about the next big features for your product. The Ruby community is very active and provides very nice modules (=gems), which provide a specific functionality and usually do it very well.

What is Watir?

Watir stands for Web Application Testing in Ruby, http://watir.com. It’s a framework, which drives the browser programmatically. Currently the officially supported browsers are IE and Firefox, but gems also exists for Chrome and Safari. Also Opera is working on a port of their own, which they are using in their own development (http://my.opera.com/core/blog/2009/03/06/test-automation-with-operawatir). Unfortunately, it is not available for outsiders yet, which makes guaranteeing websites work on Opera more difficult than it should be.

What about Ruby on Rails?

The single most important reason for Ruby gaining a lot of attraction in the recent years is the Ruby on Rails web development framework, http://rubyonrails.org. The framework enables quicker web development with it’s inbuilt support for database access. It’s actually not just support, but ActiveRecord is one of the fundamental technologies behind RoR and makes it especially suited for database driven applications.

How is that related to testing?

Watir is great for web automation, and we have used it in extensive automation projects. There is lots of documentation available for the basic usage, but as always, best practices for implementing automation test projects in different types of situations are more difficult to find and require some trial and error to find the best approach.

Typically, one of the main points to consider is how easy the test cases will be to maintain. Writing one or ten test cases is easy without any structure, but scaling the automation suite for hundreds or thousands of test cases requires careful planning. Many of the same rules apply as for any software development project. As most of the testers do not have a developer background, this can be a challenge in the beginning.

There’s is nothing stopping testers taking advantage of the already well thought out features of Ruby on Rails what comes to database access (ActiveRecord) and for sending email (ActionMailer). Database access can be used to verify that a form actually posted the values and they were stored correctly in the database. Email can be, for example, used for sending test reports directly from test automation. There are clear synergies in understanding both of these technologies when aiming the create good test automation projects. And when using the already available gems for the tasks, you’ll save time for actual automation work.