Rails provides some flexible and fairly short controller methods for responding with an HTTP error code. Given that controllers are complicated enough by nature, I’m always looking for ways to DRY them up and make the code easy to understand. So here are some controller methods that make it really easy to provide correct HTTP error responses to clients.
Continue reading “Tidier HTTP error responses in Rails controllers”
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.
Continue reading “Proper Error Handling in Rails Controllers”
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.
Continue reading “A Cucumber step to test for a YM4R Google Map”
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.
Continue reading “Fancier Stubbing of GeoKit for Rails unit tests”