Rake4 is a Ruby program that builds other Ruby programs. It knows how
to build those programs by reading a file called Rakefile, which includes a
set of tasks. Each task has a name, a list of other tasks it depends on,
and a list of actions to be performed by the task.
When you run therailsscript to generate a Rails project, you automatically
get aRakefilein the top-level directory of the project. And right out of the
chute, the Rakefile you get with Rails includes handy tasks to automate
recurring project chores. To see all the built-in tasks you can invoke and their descriptions, run the following command in the top-level directory of your Rails project.
depot> rake --tasks
Let’s look at a few of those tasks.
Make a Test Database
One of the Rake tasks we’ve already seen,clone_structure_to_test, clones the
structure (but not the data) from the development database into the test database. To invoke the task, run the following command in the top-level directory of your Rails project.
depot> rake clone_structure_to_test
4http://rake.rubyforge.net
Report erratum
RUNNINGTESTS WITHRAKE 166
Running Tests
You can run all of your unit tests with a single command using theRakefile
that comes with a Rails project.
depot> rake test_units
Here’s sample output for runningtest_unitson the Depot application.
depot_testing> rake test_units
(in /Users/mike/work/depot_testing) . . .
Started
...
Finished in 0.873974 seconds.
16 tests, 47 assertions, 0 failures, 0 errors
You can also run all of your functional tests with a single command:
depot> rake test_functional
The default task runs thetest_units andtest_functional tasks. So, to run all
the tests, simply use
depot> rake
But sometimes you don’t want to run all of the tests together, as one
test might be a bit slow. Say, for example, you want to run only the
test_update( ) method of the ProductTest test case. Instead of using Rake,
you can use the-noption with the ruby command directly. Here’s how to
run a single test method.
depot> ruby test/unit/product_test.rb -n test_update
Alternatively, you can provide a regular expression to the -n option. For
example, to run all of the ProductTestmethods that contain the word vali-
datein their name, use
depot> ruby test/unit/product_test.rb -n /validate/
But why remember which models and controllers have changed in the last few minutes to know which unit and functional tests need to be to run?
Therecent Rake task checks the timestamp of your model and controller
files and runs their corresponding tests only if the files have changed in
the last 10 minutes. If we come back from lunch and edit thecart.rb file,
for example, just its tests run.
depot> edit app/models/cart.rb
depot> rake recent
(in /Users/mike/work/depot_testing) /usr/lib/ruby/gems/1.8/gems/rake-0.5.3/lib/rake/rake_test_loader.rb test/unit/cart_test.rb Started .. Finished in 0.158324 seconds.
2 tests, 4 assertions, 0 failures, 0 errors
Report erratum
RUNNINGTESTS WITHRAKE 167
Schedule Continuous Builds
While you’re writing code, you’re also running tests to see if changes may have broken anything. As the number of tests grows, running them all may slow you down. So, you’ll want to just run localized tests around the code you’re working on. But your computer has idle time while you’re thinking and typing, so you might as well put it to work running tests for you.
All you need to schedule a continuous test cycle is a Unix cron script, a
Windowsatfile, or (wait for it) a Ruby program. DamageControl5 happens
to be just such a program—it’s built on Rails and it’s free. DamageControl lets you schedule continuous builds, and it will even check your version control system for changes (you are using version control, right?) so that
arbitrary tasks of your Rakefile are run whenever anyone on your team
checks in new code.
Although it’s a book for Java users, Pragmatic Project Automation [Cla04]
is full of useful ideas for automating your builds (and beyond). All that adds up to more time and energy to develop your Rails application.
Generate Statistics
As you’re going along, writing tests, you’d like some general measurements for how well the code is covered and some other code statistics. The Rake statstask gives you a dashboard of information.
depot> rake stats
+---+---+---+---+---+---+---+
| Name | Lines | LOC | Classes | Methods | M/C | LOC/M |
+---+---+---+---+---+---+---+ | Helpers | 15 | 11 | 0 | 1 | 0 | 9 | | Controllers | 342 | 214 | 5 | 27 | 5 | 5 | | APIs | 0 | 0 | 0 | 0 | 0 | 0 | | Components | 0 | 0 | 0 | 0 | 0 | 0 | | Functionals | 228 | 142 | 7 | 22 | 3 | 4 | | Models | 208 | 108 | 6 | 16 | 2 | 4 | | Units | 193 | 128 | 6 | 20 | 3 | 4 | +---+---+---+---+---+---+---+ | Total | 986 | 603 | 24 | 86 | 3 | 5 | +---+---+---+---+---+---+---+ Code LOC: 333 Test LOC: 270 Code to Test Ratio: 1:0.8
Now, you know the joke about lies, damned lies, and statistics, so take this with a large pinch of salt. In general, we want to see (passing) tests being added as more code is written. But how do we know if those tests are good? One way to get more insight is to run a tool that identifies lines of code that don’t get executed when the tests run.
5http://damagecontrol.codehaus.org/
Report erratum
PERFORMANCETESTING 168
Ruby Coverage6is a free coverage tool (not yet included with Ruby or Rails)
that outputs an HTML report including the percentage of coverage, with the lines of code not covered by tests highlighted for your viewing pleasure.
To generate a report, add the-rcoverageoption to therubycommand when
running tests.
depot> ruby -rcoverage test/functional/store_controller_test.rb
Generate test reports often, or, better yet, schedule fresh reports to be generated for you and put up on your web site daily. After all, you can’t improve that which you don’t measure.