advertisement

Print

Behavior Driven Development Using Ruby (Part 3)
Pages: 1, 2, 3, 4, 5

Checking for Missing Specs with RCov

An easy way to identify potential problem areas in your code is to find areas that aren't even being executed by your specs. RCov is a simple and powerful code coverage tool that does this kind of analysis, and though it can also be used with Test::Unit, it is trivial to get it working with RSpec as well.

Here's the basic Rakefile I'm using for the Dots game code:

require 'rake'
require 'spec/rake/spectask'

desc "Run all examples" 
Spec::Rake::SpecTask.new('examples') do |t|
  t.spec_files = FileList['spec/*_spec.rb']
end          

desc "Run all examples with RCov" 
Spec::Rake::SpecTask.new('examples_with_rcov') do |t|
  t.spec_files = FileList['spec/*_spec.rb']
  t.rcov = true
  t.rcov_opts = ['--exclude', 'spec']
end

Now, when I run rake examples_with_rcov, I get nice HTML reports that look like this:

figure
Figure 1.

It's pretty easy to see which classes were and were not developed using BDD. The neat thing is that RCov does a line-by-line output of your code, highlighting lines that were not run in red:

figure
Figure 2.

Of the interface implementation, this was the easiest method I could pick to layer some specs on top of. Going back to the outline we started earlier, something like this is enough to get us coverage:

describe "An interface" do

  it "should prompt for players" 

  it "should prompt for grid size" 

  it "should be able to update board display" 

  it "should display a score board" do
    game = mock("game")
    players = %w[Greg Pete Paul] 
    game.should_receive(:players).and_return(players)
    players.each do |p|
      game.should_receive(:score).with(p).and_return(0)
    end 

    @interface.score_board(game).should == " Greg: 0 Pete: 0 Paul: 0"    
  end

  it "should prompt for a players move" 

end

Even though we're using mocks to avoid passing in a real Dots::Game object, you can see that this simple example is enough to at least make sure this code is running, and working as expected:

figure
Figure 3.

With each small change, our overall coverage starts to look better:

figure
Figure 4.

Though RCov is very handy for letting you know how much you suck, it can't do much for telling you whether your specs are of any quality. We'll now take a look at the next step you can take to beat up your specs once you know they're at least running your code.

Pages: 1, 2, 3, 4, 5

Next Pagearrow