Testing your Ruby programs with Rake

How many times have you been told to make tests? How many times have you pushed them off believing that they are necessary? If your answer many to both, you may want to reconsider that approach to building software.

I myself chose to go the lonesome path a long time ago initially of writing my programs in a certain way that I wouldn't have to write tests within the program itself. However the core of TDD allows your program to maintain integral features which cannot break without you knowing about it first.

I think that its very important in retrospect to consistently build your program with tests, (unless its fairly simple like printing out text and does not require multiple libraries).

I will move onto Rspec later but first get to know that you don’t want to just write code, for what you want your program to do ; you want to write tests for what your program is expected to do so that any change in the code that you write that alerts in throwing an exception will alert you immediately.

As most of you should know Rake is built into the Ruby language and is set by the Rakefile , which you must create in your project directory first.

The Rakefile itself is similar to a Makefile from C, which basically is a textfile with prescribed syntax that allows you to set the rules for your application build process.

Within your Rakefile you want to require rake’s testtask directory because we want to write how Rake should test our program tasks.

require ‘rake/testtask’

then you want to initialize a new TestTask object and assign a couple values to it.

This automates our test tasks to consistently loading “tests” from the load path and this might lead you to then say “Where are these tests?”

Well we have to make our “tests” directory or what ever you want to match the TestTask.libs and TestTask.test_files. Im going to go with tests for fairly self-explanatory reasons.

Once you are inside tests/ then create your test_FILLINHERE.rb

Inside that file you can test various features of your program by requiring the files needed to add them into the Rake environment.

So since im talking about general testing you will want to require whatever file you want, and then you want to require “test/unit”.

require “directory/filename.rb”

require “test/unit”

Afterwards you will want to make a new class TestFILLINHERE have it inherit from Test::Unit::TestCase. We will be using test/unit’s TestCase class because it allows us to test units of our application and apply cases to these units.

Once inside you can create test methods which start with test usually and then fill in your required tests. Now within the scope of your function you will have to build the unit of your application with the objects you want.

Now the assert_equal and assert_not_same functions are inherited from Test::Unit::Assertions. This is your toolkit for defining Unit tests.

To run your tests cd into your project root directory and run the rake command.

rake tests — Runs all the Functional Unit and Integration tests.

rake -T — Shows you all the rake commands that you can run

Notice how I have sub categorized the tests into three sections , Unit , Functional and Integration.

In the future you will want to add directories into you “tests” directory. These should be “unit” , “functional” and “integration”.

Unit Tests

Unit tests are the most fundamental features of your application, the atomic elements for how your tests function. Ie given a class X with a certain state , method y should result in Z. Eg: calling .pop on an empty stack should throw a exception. The code within unit tests should be done in memory. Ie the test code and the code under test shouldn’t

1. Hit the Database
2. Access the Network
3. Call out to non-trivial collaborators
4. Create another thread
5. Anything else that is overcomplicated or remotely slow

If there are any dependencies which are fairly slow/complicated these should be mocked so you can focus on what the actual unit is doing. Basically unit tests are short and easy to debug and reliable due to small amounts of dependencies.

I’ll go into integrated and functional tests later but remember that unit tests are the smallest elements of your tests and should only be done in memory and has very few dependencies.