{"id":600,"date":"2008-12-29T09:39:07","date_gmt":"2008-12-29T17:39:07","guid":{"rendered":"https:\/\/www.ultrasaurus.com\/sarahblog\/2008\/12\/rails-2-day-4-rcov-and-more-behavior-driven-development\/"},"modified":"2008-12-29T09:39:07","modified_gmt":"2008-12-29T17:39:07","slug":"rails-2-day-4-rcov-and-more-behavior-driven-development","status":"publish","type":"post","link":"https:\/\/www.ultrasaurus.com\/2008\/12\/rails-2-day-4-rcov-and-more-behavior-driven-development\/","title":{"rendered":"rails 2 day 4: rcov and more behavior-driven development"},"content":{"rendered":"

Today, we’ll follow modified steps, as recommended by Matt Wynne<\/a> who suggested refactoring to remove duplication<\/a> as an extremely important step:<\/p>\n

    \n
  1. Describe a feature<\/li>\n
  2. Execute the feature and Watch it fail<\/li>\n
  3. Write the code to make it pass<\/li>\n
  4. Refactor<\/li>\n
  5. Go to step 2<\/li>\n<\/ol>\n

    Also, since we’re using the generate scaffold command, we should remove unused code when refactoring as suggested in the original Four Days on Rails<\/a> tutorial. I’ll also be using RCov to look at how much the feature description covers the code. I think this is a helpful way of digging into what the scaffold command actually did. This tutorial picks up where day 3<\/a> finished. You can skip day 1 or 2, if you already have installed Ruby on Rails and know a little bit about it.<\/p>\n

    Today we will:<\/p>\n

      \n
    1. Install RCov<\/a><\/li>\n
    2. Look at Code Coverage<\/a><\/li>\n
    3. Write more scenarios<\/a>\n
        \n
      1. Create<\/a><\/li>\n
      2. Edit<\/a><\/li>\n
      3. Delete<\/a><\/li>\n<\/ol>\n<\/li>\n
      4. Refactor to remove duplication<\/a><\/li>\n
      5. Review what we learned<\/a><\/li>\n<\/ol>\n

         <\/p>\n

        \n

         <\/p>\n

        <\/p>\n

        Install RCov<\/h1>\n

        <\/a><\/p>\n

        Elaborating slightly on the nice instructions<\/a> on the cucumber wiki, Aslak recommends that you use spicycode’s RCov<\/a> instead of the ‘official’ one, “as it currently segfaults too much for most people’s taste.”<\/p>\n

        \ngem sources -a http:\/\/gems.github.com\ngem uninstall rcov\ngem install spicycode-rcov\n<\/pre>\n
        Second, you’ll need to open up the cucumber generated task file and set the rcov config option (add one line in bold).<\/p>\n
        in todolist\/lib\/tasks\/cucumber.rake<\/strong><\/code><\/p>\n

        \n$:.unshift(RAILS_ROOT + '\/vendor\/plugins\/cucumber\/lib')
        \nrequire 'cucumber\/rake\/task'
        \nCucumber::Rake::Task.new(:features) do |t|
        \n  t.cucumber_opts = \"--format pretty\" 
        \n  t.rcov = true<\/strong>
        \nend
        \ntask :features => 'db:test:prepare'
        \n<\/code><\/p><\/blockquote>\n
        <\/p>\n
        Look at Code Coverage<\/h1>\n
        <\/a><\/p>\n
        Now when you run:<\/p>\n
        \nrake features\n<\/pre>\n
        And you point your browser at:  http:\/\/localhost\/todolist\/coverage\/<\/code><\/p>\n
        You’ll see:<\/p>\n
        <\/a><\/p>\n
        We can see that we don’t have complete coverage in two files: webrat.rb and tasks_controller.rb  The first doesn’t matter, since it is part of the test framework (in fact there ought to be some way to exclude that), but we need to be concerned that half of our generated controller code is untested.  By clicking on the filename, we can see the detailed coverage where the lines of code that are not covered are highlighted in red:<\/p>\n
        <\/a><\/p>\n
        It is unsurprising that we’re covering just 40% of this file, since we’ve written just a single of scenario so far<\/a>. <\/p>\n
        <\/p>\n
        More Scenarios<\/h1>\n
        <\/a><\/p>\n
        Let’s look at what isn’t getting covered.<\/p>\n