I'm a Floridian web engineer who planted his roots in Paris. Some of my favorite past-times are analyzing and optimizing development processes, building solid APIs, mentoring junior devs, and long walks on the beach.

Test a will_paginate Custom Renderer 01-22-2012

I was recently working on a project where my employer wanted me to make the site's current pagination work the way the old site's pagination worked. I had recently switched over using will_paginate, and while there are a number of good resources for making customized link renderers: frivolous, thewebfellas are a few. They don't really mention testing.

While searching through the internets, I eventually stumbled upon this on tsigo's github with some specs for his renderers. For me, I just had to test an override of windowedpagenumbers, and link. Setting up the test can be seen easily enough from the github file, but essentially, you just create an instance of WillPaginate::Collection and pass that into whatever renderer you have created along with any options like so:

@renderer = LinkRenderer.new
@collection = WillPaginate::Collection.new(page, per_page, total_entries)
@renderer.prepare(@collection, options, '')

@renderer.method_name.should do_something

You will have noticed that I've stubbed out the url method. That is because we aren't using a real collection of objects and therefore there is no url to generate.

Testing File operations 03-24-2011

I've recently been working on a gem that will integrate git and pivotal into my current command-line workflow. I'll talk more about that in a future post, but check it out if you're interested. As I've been working on it, I have become increasingly aware how awesome mocking and stubbing are. I've been using mocha(gem install mocha #bros) for all of my needs and after a little playing around it has made me a very happy person. I haven't had much use for either until this gem I've been working on. The gem does more file operations that I normally do since most web stuff is heavier on the db action.

On this project I ran into an issue where I wasn't sure how to test the following code.

def load_project_id
  File.open('.git/config') do |file| 
    file.each_line do |line| 
      if line.slice('[pivotal]')
        return file.gets.tr("\s\t\n",'').split(' = ').last

For this chunk of code, I wanted to spoof the variable 'file' so that I could make sure that everything in the File.open block does what it needs to. At first I thought that there might be a way to stub the variable that comes in to the block, but it ends up there is a more straight forward thing to do. I ended up turning File.open(".git/config") into File.open(git_config) where git_config is a method that determines the git config directory based on the current working directory. This way I can test this method by stubbing the git_config method with some file I've put in the /tmp directory and keep my config files clean.

Dot-Rspec files 03-02-2011

I was recently working on a small library for assigning people a schedule and I decided to go with rspec 2 for testing. As I was working with it, I found that you can use a .rspec file to keep all of the settings in which seemed like a good idea to me. I'm used to having config files like that what with .bashrc, .rvmrc, etc. My file was laid out as such:

--format documentation

I could then run the command rspec spec/libs/* and it would run all of my tests in the desired format. I didn't want to have to specify the directory every time and so I decided to add the -I option in my .rspec file to include the directory. This, for some reason, would not work and while looking for a solution, I found the rspec 1 to 2 upgrade page with my answer.

Create a Rake Task

Under rake task it lists how you can set the options using a Rakefile, which in retrospec(...har), I should have been using anyways. I ended up using something like the following:

require 'rspec/core/rake_task'
RSpec::Core::RakeTask.new do |t|
    t.rspec_opts = ["--color", "--format documentation", "--fail-fast"]
    t.pattern = ['spec/libs/*.rb']

Now I can call my tests with rake spec.

Moral of the Story

Don't use .rspec for your rspec configurations. You'll probably end up needing a Rakefile at some point anyways so you might as well use that.

Tags: rspec ruby