Hide external access behind a small facade for easy mocking

Imagine you have validation like this, where you call the youtube website to make sure the provided video id is valid:

    1 class Video < ActiveRecord::Base
    2   def validate
    3     response = Net::HTTP.start('youtube.com') { |http| http.head("/v/#{self.youtube_video_id}") }
    4     unless response.is_a?(Net::HTTPOK)
    5       errors.add(:youtube_video_id, "no valid Youtube Video ID")
    6     end
    7   end
    8 end
    9 

Actually, this code fragment is a pain in the neck to test. If you hide the external access behind a small facade (or wrapper if you like) like this:

    1 class YouTube
    2   def self.video_id_valid?(video_id)
    3     response = Net::HTTP.start('youtube.com') do |http|
    4       http.head("/v/#{self.youtube_video_id}")
    5     end
    6     response.is_a?(:Net::HTTPOK)
    7   end
    8 end
    9
   10 class Video < ActiveRecord::Base
   11   def validate
   12     unless Youtube.video_id_valid?(self.youtube_video_id)
   13       errors.add(:youtube_video_id, "no valid Youtube Video ID")
   14     end
   15   end
   16 end
   17 

it's much easier to test:

    1 # video_spec.rb
    2 describe Video, "validations" do
    3   before(:each) do
    4     @video = Video.new(:youtube_video_id => 'iY6VroKoB8E')
    5   end
    6   it "should succeed with correct youtube video id" do
    7     Youtube.stub!(:video_id_valid?).and_return(true)
    8     @video.should be_valid
    9   end
   10   it "should fail with incorrect youtube video id" do
   11     Youtube.stub!(:video_id_valid?).and_return(false)
   12     @video.should_not be_valid
   13   end
   14 end
   15 

Test first

There is a long history of postings and even books written about this topic. Most of the time it is called test-driven development (or design resp.) or behavior-driven development, what doesn't matter now. The important thing about it is that you do it first, before writing a single line of code.

Why should I do that?

Most important, it helps you to look at your application from a different point of view. You just concentrate on the desired behavior, and don't think about the how (you would do it), just the what (to do). Next, when writing the tests after your code, you simply test too much or too less, and are too close to the implementation details. And finally, it's best practice to write a test first for every bug you encounter, just to reproduce the error and make sure that it will never ever happen again!

Are there any problems?

One might say your tests are too integrative, meaning that you focus on more than the unit to test, and you probably and simply test too much. But I think it's just a matter of experience, and at the end you can optimize your tests just like the application code later on.

A simple example

You start by describing what your application, method or class should behave like. The user model in this case:

    1 # user_spec.rb
    2 describe "A user's display name" do
    3
    4   it "should equal his/her login if no other name is available"
    5
    6   it "should equal his/her full name if available"
    7
    8 end
    9 

What do we have here? First, at line 1 we defined a context for our test, using RSpec's describe block (have a look at RSpec documentation for details). Furthermore we have two behaviors (it-blocks), defining what we expect our system to behave like. Let's go a step further and fill these up a bit:

    1 # user_spec.rb
    2 describe "A user's display name" do
    3   it "should equal his/her login name if no other is available" do
    4     user = User.new(:login => 'dude')
    5     user.display_name.should eql('dude')
    6   end
    7   it "should equal his/her full name if available" do
    8     user = User.new(:login => 'dude', :name => 'Thorsten Böttger')
    9     user.display_name.should eql('Thorsten Böttger')
   10   end
   11 end
   12 

At the very end, you write the application code, and fire up the tests to check, if it behaves

the way you wanted while writing the tests:

    1 # user.rb
    2 class User < ActiveRecord::Base
    3   def display_name
    4     name.blank? ? login : name
    5   end
    6 end
    7 

Welcome

Welcome aboard this blog about best practices for testing Ruby on Rails applications. We are Jan Krutisch and Thorsten Böttger, two Rails hackers from Hamburg, Germany.