Pervasive Code

Rails controllers can get out of hand if you’re not very careful. Skinny Controller Fat Model is a great start. But what about handling errors? Isn’t it enough to just let Rails catch your exception and show a 500 Server Error page?

No, it’s not. Falling back on 500 Server Error for everything outside of the “happy path” through your code is sloppy coding.
Read the rest of this entry »

I had some problems with a view in a Rails app that was conditionally hiding a Google Map that was generated using the YM4R plugin. I don’t usually test views in unit tests, and this logic depended on a particular situation with the data behind the view, so I decided that this would be a good candidate for a Cucumber feature.

Here’s the Cucumber step implementation I wrote.
Read the rest of this entry »

I’m working on a Rails app that uses the ym4r_gm plugin, getting Google to do the geocoding for Thentic. I liked the idea of stubbing the web service call, because all those calls to an external service add up to over 20 seconds of test suite run time(!). That’s almost half of the 50 second run time of my unit tests (and 50 seconds is much too long for a unit test suite).

I found a good starting point at geokit stubbing for faster tests. I also wanted a way to stub a geocoding failure, and a way to prevent any unit tests from using the real geocoding web service.

Here’s how I did it.
Read the rest of this entry »

The new features in Ruby on Rails 2.2.2 have been well documented, and I’m looking forward to using several of them on WhatYouAte.com. If you’re reading this you probably are too.

However, if you’re upgrading an existing project and you’re sticking with official releases (as opposed to edge Rails) like I am, your code probably needs some tweaking to work with Rails 2.2.2. Mine certainly did. Although there were a lot of failed tests with ugly stacktraces, there were only a few API changes in Rails that needed to be accomodated to fix them all. Here’s a list of the changes that broke my app, and what I had to do to get it working again.
Read the rest of this entry »

I subscribe to dozens of tech blogs (including but not limited to Ruby and Rails), and although I’ve seen quite a lot of commentary about TDD and BDD, I’m not sold on either of them yet. TDD is interesting, but BDD seems like a waste of time. But I am completely sold on automated testing in general. I write lots and lots of tests and make sure using rcov that my tests cover all of the code.

Getting 100% coverage isn’t easy. In general it means you definitely can’t just write a single test case per method and declare victory when it passes. When the number of possible combinations of inputs (method arguments and/or mock objects) and expected outputs (return values, exceptions, and side effects) becomes large, then the potential for copy-and-paste errors in your test code becomes large, and legibility becomes an issue. This is the point at which I find the recent fascination with writing tests in a near-natural-language DSL to be a distraction. It’s orthogonal to the problem I’m dealing with, which is how to comprehensively test the code. In other words, the problem is not making a small number of tests more readable, but concisely expressing a large number of input/output combinations and a large number of different tests, and making it all readable.

I assume that there are others working on this problem too, so I’ll describe some of the things I’ve come up with, and hopefully if you have any good ideas you’ll post them in the comments section.

Read the rest of this entry »