So I have a Rails app that’s broad but not very deep: there are a lot of different types of URLs and thousands of pages, generated dynamically or built through a CMS. No one page is that complicated, but there’s a fair amount of shared code and thus some tentacles throughout. Yes, I should have written behavior-level and unit-level tests from the beginning, but I didn’t, don’t judge me.
Anyway, after I broke the site yet again, I realized what I really wanted was a post-release test suite – I wanted to test a whole bunch of pages in production and make sure they’re still rendering.
Stealing from the Net::HTTP canonical examples, then, I wrote a standalone script:
URIs = ['http://example.com/', 'http://example.com/page/2']
puts “Running URL Test Suite…”
URIs.each do |uri|
url = URI.parse(uri)
req = Net::HTTP::Get.new(url.path)
res = Net::HTTP.start(url.host, url.port) { |http| http.request(req) }
unless res.code == ’200′
puts “ERROR: #{uri} #{res.code}”
end
end
puts “Test Suite Complete!”
Then, since I deploy directly with git, I added a call to this script in my post-receive hook. As long as I watch the deployment (which I do anyway), I’ll see if there’s a problem and fix it immediately. (I can handle a few minutes of downtime or just roll back.)
There are obvious improvements to this (like not storing the URLs in the file), and this doesn’t handle redirect, workflow, or authentication scenarios, but it’s a perfectly acceptable 99% case for a content site.
Note that if you are doing Rails development and you’ve built a custom 404 page, you’ll want to make sure that you’re actually returning a 404 status code, or this won’t catch errors: you can test your status codes, and if you aren’t, you can add code in your application controller to do the right thing.
Recent Comments