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"'examples') do |t|
  t.spec_files = FileList['spec/*_spec.rb']

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

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

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 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] 
    players.each do |p|

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

  it "should prompt for a players move" 


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 3.

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

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