Why Rake is a great tool for test run automation

The more I use Rake for automation of our testing process, the more I like it.  Where I work, we have a Java-based web application.  However, I have found that using Rake, not Ant, is definitely the tool of choice for automating the configuration and running of our QA tests.   Here are some of the reasons:

• Rake uses Ruby scripts as their ‘rakefile’ – Ant uses XML files, which are great for storing structured data but have no real ability to perform logic or make decisions.  Rake, on the other hand, uses actual Ruby syntax within their ‘rakefile’, which means you have full access to the Ruby ecosystem.  This allows you to utilize decision structures, closures, even classes if you desire.
• Rake is fully supported by Intellij and TeamCity – I am not sure what Rake’s support is in other environments, but our development/automation environment is Jetbrains’ Intellij for the IDE and TeamCity for the build automation.  Both have terrific support for Ruby and Rake.
• Rake has great support for RSpec – RSpec is our test framework…and Rake has great support for it. 

Some of our tests in the future might be Jython tests run from the server (under the JVM), but they can still be easily launched from a Ruby/RSpec script (via a web services API).  This is ideal, because it gives us the best of both worlds…the ability to quickly script tests through Ruby when possible, but also the ability to access the product’s underlying classes when we need to.

Trying out my new look...tell me what you think!

Java properties files - in Ruby

One nice thing about Java is its use of properties files, which are text files with a .properties extension that contain key-value pairs of data. This way, changeable data can be stored in a file separate from the code. There is a way to do this in Ruby too, with YAML files and the Ruby YAML module.

First, create a YAML file. This is simply a text file with a .YAML extension, and with key-value pairs of data seperated by a colon. For example, let’s say you wanted to store a user name and password to run your tests with (for illustration purposes – normally it’s not a good idea to store a password in a text file). You’d set up your properties.yaml file thus:

username : jim
password : mypassword

Save the file. Now, you can access those properties through Ruby. Since I love using IRB to test functionality interactively, I’ll recommend you now fire up IRB. For this example, run IRB from the directory you created the YAML file.

Once IRB is up, require the YAML module:

require ‘yaml’

Now, load the properties file and assign it to a variable:

properties = YAML.load_file( './properties.yaml' )

Once this is done, you can use the properties from your YAML file. Let’s say you had a login() method that takes two parameters, the username and password. You could at this point run your method thus:

login(properties[“username”], properties[“password”])

This will run your login() method with the username and password you defined in your properties.yaml file.

Design principles:

• For properties that will not change, I’d suggest you can define those in helper modules.
• For properties that will change in different environments, put them in a YAML file. This makes it much easier to customize a deployment.