Archive for the ‘Testing’ Category
Do dynamic languages need more tests than static languages?
Recently I made an error in a Ruby program (a Rails application) that I wouldn’t have been able to make in a Java program. I renamed a model method manually — because another class had a method with the same name, and RubyMine’s Rename Method refactoring would have renamed both methods — and although I renamed the method itself and uses of the method in the model object’s spec, I missed uses of the method in a controller and mocks of it in the controller’s spec. All of the tests passed, but the application broke. “Gee,” I thought, “if I’d had to compile everything first, that couldn’t have happened.”
Upgrading GWW from Rails 2, RSpec 1 and prototype to Rails 3, RSpec 2 and jQuery
GWW originated on Rails 1; I upgraded it to Rails 2 last year. I’d been putting off the upgrade to Rails 3 until a bug in Phusion Passenger which breaks redirects in Apache httpd was fixed, but I want to use a database adapter which supports MySQL spatial features, and that requires Rails 3. I said goodbye to page caching until (crossing fingers) Passenger 3.0.6, made a branch and started editing my Gemfile.
Although Rails 3 has been released for more than half a year, upgrading involved many hiccups and a couple of landslides. I’d have been happy to just update my gems and be done with it, but I had to hunt around enough that it seemed worth logging what I did in case it helped someone else. I’ve kept it as short and to-the-point as I could. Although I fixed all of the deprecations that Rails 3 reported as I encountered them, I won’t mention them further, since in every case they were completely clear and fixing them only required following instructions. I’ve also left out a handful of odd little incorrectnesses in GWW which worked in Rails 2 but broke in Rails 3, since the details probably won’t interest anyone else and the fixes were obvious. Otherwise, here’s how the upgrade went.
Homebrewed ActiveRecord test object factories for rspec
I recently took GWW from a handful of Test::Unit tests to 100% test coverage. It took some good tools (rspec and RR (Double Ruby) are both terrific), but what I didn’t do was use either of the widely used test object factory libraries, factory_girl or Machinist. I wasn’t going to use Rails fixtures, either — fixtures are just wrong — but the factory libraries rubbed me the wrong way. I could point to bits of each tool that weren’t exactly what I wanted, but the real reason I didn’t use either one was that they both seemed a little much when all I wanted to do was construct a few objects. Yes, I recognized the sound of a wheel about to be reinvented, but I went ahead anyway, and I ended up with a small amount of code very well tuned to my needs, and a couple of nice features that I don’t think the off-the-shelf solutions provide.
Test patterns: red-green-refactor vs. frequent committing
Agile and lean principles lead to committing frequently, each commit potentially deployable to production. I’ve always been one to save my work often, and I commit often, not just whenever I finish an entire task, but whenever I’ve written enough code to justify running my tests, I do so, and they pass. This always seems like the right thing to do: it’s usually easy to break down big tasks into small, committable, deployable bits, and I can almost always point to the value in each commit, whether an implemented test, a refactoring or just a spelling fix. But I recently found myself in a situation where I realized that committing a (correct) test and its implementation that I’d just written would introduce a bug.
Test patterns: One test per path
I’ve seen many test suites which were much less thought through and much less well factored than the code they tested. But that’s not right: Tests drive the code, so tests are at least as important as code. You should care about the quality of your tests just as much as you do the quality of your code, and refactor your tests just as vigorously as you do your code. Here, then, are some thoughts on one aspect of good test design: the One test per path pattern.
