brighter.net

I have recently started using a gem called FakeWeb to fake http requests in my specs. It’s awesome - FakeWeb allowed me to ensure that I had stubbed out all external API requests (on a rather API-dependent application) with one line of code:

   1  # prevent specs from trying to hit external api's
   2    require 'fakeweb'
   3    FakeWeb.allow_net_connect = false  

However, I ran into an issue with it on another project that needed to block all requests except those going to a specific service. The issue was that each request had a different query string, and soon our spec helper was full of lines like this:

   1  FakeWeb.register_uri("http://www.external.service.com/api/some/script?crazy=true&param=foo&list=0&whatever=3", :string => "foo")
   2    FakeWeb.register_uri("http://www.external.service.com/api/some/script?crazy=true&param=foo&list=0&whatever=4&additional=etc", :string => "foo")
   3    FakeWeb.register_uri("http://www.external.service.com/api/some/script?crazy=true&param=foo&list=0&whatever=5&additional=bar", :string => "foo")
   4    FakeWeb.register_uri("http://www.external.service.com/api/some/script?crazy=true&param=foo&list=0&whatever=6", :string => "foo")

The query params differed depending on the request issued. Where we really got into trouble was with escaped URIs - these are harder for mere humans to read, and we missed differences in the longer ones quite a few times.

   1  FakeWeb.register_uri("http://example.com/?a=%09%0D&b=%09%0D&ca=%09dog%4D&d=%26%0D&g=%09%0D&b=%09%0D&ca=%09dog%4D&d=%26%0D")
   2    FakeWeb.register_uri("http://example.com/?a=%09%0D&b=%09%0D&ca=%09dog%4D&d=%26%0D&g=%09%0D&b=%09%0E&ca=%09dog%4D&d=%26%0D")
   3    FakeWeb.register_uri("http://example.com/?bc=%09%0D&b=%09%0D&ca=%09dog%4D&d=%26%0D&g=%09%0D&b=%09%0D&ca=%09dog%4D&d=%26%0D")

This prompted me to ask, “why not pass a regexp to FakeWeb’s register_uri method?” That way, we could pass something like /example.com\/?a=(.*)$/ for example and not have to worry about the query parameters changing… and thus have less clutter in our spec helper.

FakeWeb didn’t support this (it allowed you to pass URI and String objects) but it wasn’t too hard to add it. You can check out my fork here:

FakeWeb with Regular Expression support for registering URIs

I hope that other people find this useful. Oh yeah - please let me know on github if you find a bug in the code, and of course, feel free to fork it too!

Ever find yourself in a situation where you wanted to delegate attributes from one model to an associated model unless they were specified in the original model?

I did, and I came up with a revamped version of Rails’ delegate method that not only checks if the original model has a value specified before delegating it to the associated model, but also checks that the associated model exists.

Grab the gist here:

http://gist.github.com/70186

Example usage is included in it.

I’m really excited to be speaking at the Golden Gate Ruby Conference. The current speaker lineup is fantastic.

Hopefully, the work I’ve been doing on an OpenMRS gem will be complete by then :)

How much time do you spend in the stack trace of your testing framework, be it RSpec, Test::Unit, Shoulda, or otherwise, vs debugging actual problems in code you have written?

I’ve seen and experienced much time and effort spent trying to figure out why something works in production/development environments but does not work in test. Admittedly this is sometimes due to a bug in the code I (or a colleague) wrote, sure. However, I’ve found fairly often that it’s due to an implementation discrepancy between the testing framework and the application framework.

To be more specific, between Spec::Rails and Rails.

Don’t get me wrong: I like RSpec’s syntax. When I started using it after Test::Unit I found myself more productive. I can grok specs better than tests, most definitely. However, I would like to spend less time trying to fix something that ain’t broken in my application.

I would like to avoid inspecting my test framework’s implementation of, say, render, to figure out why it’s giving me different results than end users or developers will ever see.

I’ve been told that frameworks like RSpec re-implemented parts of Rails because these parts were under active development. I totally get that it’s hard to write a testing framework against a moving target. Again, I like RSpec, I don’t want to seem like I’m picking on it. I have the most total and recent experience working with RSpec though, so it’s the one that comes to mind.

Do you spend less time going down the backtrace rabbit hole with Test::Unit or Shoulda? If so… why is that?

I’m working on an informal case study comparing RSpec and Shoulda with an emphasis on developer productivity. I’ll be posting the results to this blog and discussing them with my colleagues at Hashrocket. I look forward to hearing your - yes you - $0.02 on the matter.

Danke!

I’m still on a quest to get more things done, and happily, I can report that I’m succeeding. New jobs, cities, apartments and the like take a bit of time to adjust to, though, so the going can feel frustratingly slow (to me) at times.

The shutdown of my favorite task manager yet - Sandy - just made things worse.

I’ve been looking for a replacement and as of yet have not found an adequate one. I’m using a mixture of Things, iCal and Backpack. I just installed and began to try out a new one called The Hit List, but so far, I’m not exactly sure how its feature set differs from Things.

While searching for a better way I found this interesting collection of interviews with developers and other assorted technology-involved people on what applications they use and how they get things done.

Without further ado, here it is: on waferbaby no less!