There are several reasons why you should test your Rake tasks:
- Rake tasks are code and as such deserve testing.
- When untested Rake tasks have a tendency to become overly long and convoluted. Tests will help keep them in bay.
- As Rake tasks typically depend on your models, you (should) loose confidence in them if you don't have tests and are attempting refactorings.
If you'd like to display colorized output like this you can specify the appropriate custom reporter class using the CEDAR_REPORTER_CLASS environment variable. We do this in our Rakefiles, like so:
task :specs => :build_specs do ENV["DYLD_FRAMEWORK_PATH"] = BUILD_DIR ENV["CEDAR_REPORTER_CLASS"] = "CDRColorizedReporter" system_or_exit(File.join(BUILD_DIR, SPECS_TARGET_NAME)) end
You can set the environment variable in whatever way works for you. You can also set it to any reporter class you choose, so customize away.
One of the most common complaints I've read about OCUnit, the unit testing framework built into Xcode, is that the tests you write with it won't run on the device. In addition, I personally have found the process of setting up a target for tests that depend on UIKit confusing and onerous. So, one of our goals for Cedar was to make testing UI elements easy (or easier), by making it easy to run specs in the simulator or on the device.
Probably the second most common complaint I've read about OCUnit is that the tests run as part of the build. This makes the test output difficult to separate from the build output, and makes it impossible to use the debugger when running tests. So, in addition to making it easy to run specs on the device, we wanted to be able to run them as a separate, debuggable executable.
Finally, we consider it important that our specs run in our CI system. That means we wanted to be able to run Cedar specs from the command line, and get an exit code signifying success or failure. At the same time, some of us appreciate the value of the green/red feedback for specs passing and failing, so sometimes we like a nice UI. As of today, Cedar will accommodate all of these various requirements.
A few days ago I finally discovered why rake db:migrate:redo consistently angers me nearly as much as watching Paula Dean deep fry the vegetable kingdom. As any devoted connoisseur of the db rake tasks in Rails knows, db:migrate:redo always leaves your schema.rb file in the wrong state. The reason, as mentioned in our standup blog, is that rake will only invoke a given task once in a particular run.
To trivially test this try running a single task twice:
rake db:rollback db:rollback
You'll find that your database only rolls back one migration. Now, you can set the STEP environment variable when calling db:rollback, but this is, as I said, a trivial example. It gets worse.
Old Version Woes
At standup today, it's been reported that Hpricot 0.6.161 doesn't work on our Windows VM sandbox setup, while the newest version: 0.6.164, is just peachy. So watch for this and perhaps get to upgradin'.
Likewise a bug in Rake 0.8.3 breaks our CI behavior, but is apparently solved in the 0.8.4 release candidate, a.k.a. 0.8.3.99, which can be found on Jim Weirich's github.
So that's it for now. This is one of the hazards and boons of the world of fast-moving open-source projects. Bugs happen, as in all software, but they seem to be solved quickly, or else there's always room for you to dig in. So be aware and look out for the next version!
- IntelliJ IDEA 8 was officially released over the weekend.
Ask for Help
"We're having an issue with a long running Ruby process consuming too much memory and failing. What tools are available for finding and patching Ruby memory leaks?"
Several tools were suggested:
- Valgrind - Considered very powerful but difficult to use. "It will do what you want if you can figure out how to properly ask it to do so."
- BleakHouse - Ruby specific leak detection. It's available as a gem called "bleak_house"
- Leaks - This is native to OSX. The Google Web Toolkit uses this for leak detection.
- DTrace - Also a native OSX tool. There was a RailsConf presentation on Everyday DTrace on OSX.
"Rake will often silently 'fail' when running RSpec. It will not blow up but rather silently quits in the middle of the suite. This seems to happen intermittently, usually on the first run of our test suite. If we run the suite again, it works."
It was suggested that this might be a Rake version issue since there have been other test suite problems with Rake 0.8.3. Though, this particular type of problem was not identical to previous Rake versioning issues and may be something altogether different.
Keep reading for a more detailed description of this weird RSpec + Rake issue.
We've had some trouble with test task errors causing failing builds on our continuous integration boxes ever since the release of the version 0.8.3 rake gem. Sound familiar? Read on!
Tired of rake hiding your error stack trace?
(See full trace by running task with --trace)
You can have rake always show your error stack trace by going into your project's Rakefile and setting:
Rake.application.options.trace = true
Now you never need to worry about passing --trace again.