Stealing Let from Rspec

Since Rspec 1.3, you could define variables in example groups that cascaded down, thus more or less eliminating the need for a before block. You do this by calling let(). By defining them with the right words, the spec code gets simplified and reads more naturally. I found it weird that it would be named after something I kept seeing around in Lisp, so I looked it up and found this. I did not understand it at all. When I cracked open the Rspec, I found an absurdly simple implementation: the Let module defines a memoized method when you call let. Since Rspec 2 breaks up examples into their own class, you get the cascading effect simply from Ruby inheritance and scoping. Dead simple. Most of the text in that file is actually documentation.

This memoized patterns happens all over the place. One example is in inherited_resources:

class ProjectsController < InheritedResources::Base
  protected
  def collection
    @projects ||= end_of_association_chain.paginate(:page => params[:page])
  end
end

I have some similar code, but since I am working on a pure web service project, I'm not actually using any assigns. But the technique is similar. inherited_resource calls out methods that are sensible defaults most of the time. To customize it, you would override one of several of the hooks, such as object, collection, end_of_association_chain. But this looks a lot nicer using the let() syntax:

class ProjectsController < InheritedResources::Base
  include Let
  let(:collection) { @projects ||= end_of_association_chain.paginate(:page => params[:page]) }
end

And then I dropped this into app/concerns. This was actually extracted from my (working) Rails 3 web services project:

# http://gist.github.com/453389
module Let
  extend ActiveSupport::Concern

  included do
    extend Let::ClassMethods
  end

  private

  def __memoized # :nodoc:
    @__memoized ||= {}
  end

  module ClassMethods
    def let(name, &block)
      define_method(name) do
        __memoized[name] ||= instance_eval(&block)
      end
      protected(name)
    end
  end
end

I stole this from Rspec 2, then ripped out the documentation and refactored it using ActiveSupport::Concern. I added a line to make the let() bindings protected so it won't show up as an action for the controller. This is probably the behavior you'd want in non-controller anyways.

The neatest thing I had found about let() in Rspec was easily making an implicit DSL inside my spec. The fact that I can carry this over to my controller is simply too cool not to share.

Untitled Haiku #1

irb(main):001:0> lisp(:code_generator).to_ruby
=> :metaprogramming

Remarkable 4.0.0.alpha4

Rails 3.0 Beta4 is out! and thanks to Louis T. we have released a alpha4 that tracks Rails 3.0 Beta4. You will need to run RSpec 2.0 alpha11 in order to run this version.

As usual, remarkable/rails does not work. I know a lot of people have asked for this. I personally don't have a need for those macros, though there are a few who looks like they are stepping up to the plate. If you want an alternative, I highly recommend looking at the Rspec let feature which lets you do much of the same thing, minus i18n. I may publish a remarkable/rack, or at least, publish a blog post on how to do it with let. If you have not already, I highly recommend looking at the Pure RSpec slides.

Changes

• The only real change was a fix for validate_numericality_of resulting from a patch submitted for Beta4. It is Rails #4406 if you are curious.

Remarkable 4.0.0.alpha3

Remarkable 4.0.0.alpha3 has been released, thanks to João Vitor and Louis T..

Changes

1. alpha3 requires Rspec 2.0.0.alpha11


2. In keeping with Rspec 2.0.0.alpha11, the module Rspec was changed to RSpec


3. This required changes in the i18n localization files. You will now need to use r_spec instead of rspec


4. {{}} was changed to %{} as per deprecation warnings in the i18n gem


5. A Gemfile is used for the convenience of developers to install the required gems. However, we are not (yet) using Bundler.require