Archive for July, 2008

Reposting interview

Ran into this after launching up my old rails project for an interview. Figured it was worth reposting on a site that is live all the time. This interview took place back in March 2008.

Posted in Development | Comments (0)

RSpec puts my mind at ease.

Green never looked so good. Now that I am finally getting used to all the new RSpec syntax changes and settled into the 100% coverage realm, it is time to refactor some of my tests using some lambda tricks I have seen around the net.

Posted in RSpec | Comments (0)

RSpec - Mocks and Stubs

Behavior Driven Development (BDD) has become a driving force in the development industry right along the process of agile development. The two are almost synonymous with each other if you have done any sort of Agile/XP/SCRUM process on any of your projects. In the ruby world and the surrounding communities, RSpec has evolved as the leader for applying BDD practices and I felt it was about time I mastered the BDD process for all my projects.

The beauty of RSpec is in its simplicity. The code is very readable by anyone who comes across of it. For me, the syntax was the easy part. The headaches began once I tried to wrap my head around mocks (mocking) and stubs. Stubs seemed easier to start with, so I hit Google confident that my answer was just clicks away.

Well, I was wrong… After spending about an hour researching stubs, I figured maybe I should look up mocks. Unfortunately though, I got the same result posted at over 20 blogs. It was a link to a site called mockobjects. Now I am sure that somewhere on that site I could piece together an understanding of mocks and stubs, but I already had wasted a couple hours and did not have a day to spend on picking up these, seemingly simple, concepts.

Finally a ray of hope came when someone over at RailsForum posted the question I had been asking. The answers, although similar to ones I had read, made it clear as mud enough for me to take a stab at trying out some code. This is what I ended up with:

require File.expand_path(File.dirname(__FILE__) + '/../spec_helper')

describe UsersController, 'working with the show action' do

before(:each) do
@user = mock_model(User)
User.stub!(:find).and_return(@user)
end

it "should call the action successfully" do
get :show, :id => "1"
response.should be_success
end

it "should find the user" do
User.should_receive(:find).with("1").and_return(@user)
get :show, :id => "1"
end

it "should assign the found user to the view" do
get :show, :id => "1"
assigns[:user].should eql(@user)
end

end

describe UsersController, 'working with the index action' do
before(:each) do
@user = mock_model(User)
@users = [@user]
User.stub!(:find).and_return(@users)
end

it "should call the action successfully" do
get :index
response.should be_success
end

it 'should find the users' do
User.should_receive(:all).and_return(@user)
get :index
end

it 'should assign the found users to the view' do
get :index
assigns[:users].should eql(@users)
end
end

describe UsersController, 'working with the new action' do

end

describe UsersController, 'working with the create action' do

end

describe UsersController, 'working with the destroy action' do
before(:each) do
@user = mock_model(User)
User.stub!(:find).and_return(@user)
@user.stub!(:destroy).and_return(true)
end

it 'should find the user' do
User.should_receive(:find).with('1').and_return(@user)
delete :destroy, :id => 1
end

it 'should destroy the user' do
@user.should_receive(:destroy).once
delete :destroy, :id => 1
end

it 'should redirect to index' do
delete :destroy, :id => 1
response.should redirect_to(users_path)
end
end

Now I know I should have started with snippet by snippet and build up to a big post. However I feel its much easier to post the end result then break it down as we go, and its much quicker

Stubs: Simply put, it allows you to build canned responses to method calls. The reason for doing this is to maintain fast test execution by removing any database calls. Another factor is your controller tests (also known as functional tests) don’t need to rely on your models. Now when something breaks you don’t need to troubleshoot where to look since the model and controller are tested separately.

Mocks: Unlike stubs, I think of mocks as a basic barebone instance of an object. If you were to just define

@user = mock(’User’)

The @user object would respond to anything defined in your model. This means there is coupling between controller and model, unlike stubs, meaning when your tests break you need to do slightly more debugging. The amount of debugging can be minimized through good design.

To be continued.

Posted in RSpec | Comments (0)

Ruby 1.8.6 / 1.8.7 living side-by-side

With the most recent update of OSX, Apple did not update Ruby from 1.8.6 to 1.8.7 even though there are significant improvements incorporated into the new version. I decided that instead of waiting for Apple to update my default Ruby install, I would do it myself. My goal was to keep the default Apple Ruby install of 1.8.6 alone and install 1.8.7 through MacPorts. That was the easy part.

$ sudo port install ruby
$ sudo port install rb-rubygems

This will give you both ruby and a rubygems install. The way to make this installation the default is to adjust your PATH to have /opt/local/bin/ as the first item in your PATH definition (which is set in ~/.bash_profile).

PATH=/opt/local/bin:$PATH

Then reload your terminal or execute:

$ source ~/.bash_profile

Now here comes a nicety that many people will really appreciate. We want both version of Ruby to share the same gems! This is simply set (adjust paths accordingly if your not on OSX 10.5) the following inside your .bash_profile.

export GEM_HOME=`/usr/bin/gem env home`
export GEM_PATH=`/usr/bin/gem env path`

Make sure you use ` marks and not ‘ or “. This will use your 1.8.6 ruby gems as the source for your ruby gems. There you go, now you have two versions of Ruby living side by side in harmony, its so beautiful it brings a tear to my eye.

The goal of this is that you can leave the Apple install alone and if you ever want new (more current) ruby versions, you can just issue an update command via MacPorts. Thanks to drbrain for the help on troubleshooting this setup.

Tags: bash_profile, gems, install, Ruby
Posted in Ruby | Comments (1)

Living on the edge with Merb

If you have ever had the urge to live life on the edge of software development, the project you should be following right now is Merb. By now if anyone has been attending or watching the ruby community podcasts then you have heard this software mentioned. The reason I suggest merb is not because I am a huge promoter of the framework (yes, some may call it my flavor of the week) but it is just so exciting to be apart of its development.

Merb has much a growing community around it that it is hard to believe suggestions are still so welcome and encouraged. I personally have weighed by two cents on a few topics in the past week and they seem to have been taken into account. To top it all off, the lead developer Ezra Zygmuntowicz has time to answer personal questions via IRC. I doubt I would ever see DHH do this for any Rails newbie.

Anyway, its time for me to get back to checking out this elegant little framework.

Merb IRC: irc.freenode.net:6667 #merb

Tags: edge, ezra zygmuntowicz, Merb, Rails
Posted in Merb | Comments (0)

© 2008 Justin Smestad & Evalcode.com. All Rights Reserved. | Design by DemusDesign. Powered by WordPress
The views expressed on this site are solely mine and not those of my employer.