Cucumber Don't Do Affordances

‹prev | My Chain | next›

Before moving onto the next Cucumber scenario, I take a moment to see if the previous scenario missed anything. I think it likely covered just about all of the necessary behavior needed. But the legacy Rails site (and the previous incarnation as an XML-based CMS) built up many affordances that I would prefer not to lose in translation.

The homepage in Webrat save_and_open_page form:



The homepage on the legacy Rails site:



Naked CSS and missing images aside, it looks as though I am missing:

• The date of the meals


• A "Read more..." link for the meal


• Only linking to new recipes, not the entire menu


• Meals on odd numbered days have right-aligned thumbnails (added "depth")


• Text links to older meals at the bottom of the meals section

Working through that list one at a time, first up is this RSpec example:

  it "should include a pretty date for each meal" do
    render("/views/index.haml")
    response.should have_selector(".meals", :content => "May 15")
  end

This can be implemented with:

    %div= date.strftime("%B %e")

The next affordance to be added is:

  it "should suggest that the user read more..." do
    render("/views/index.haml")
    response.should have_selector(".meals a",
                                  :href => "/meals/2009/05/15",
                                  :content => "Read more…")
  end

A simple link will make that example pass.

Only including new recipes rather than the whole meal menu is a bit trickier. The examples require building up the menu, which makes for longer examples.

One or more new recipes (the meal was prepared on 2009-05-15, new recipes would be from the same day) should be comma separated:

  it "should include a comma separated list of menu items" do
    stub!(:recipe_link).
      and_return(%Q|<a href="/recipes/2009/05/15/recipe1">chips</a>|,
                 %Q|<a href="/recipes/2009/05/15/recipe2">salsa</a>|)

    assigns[:meals][0]["menu"] << "[recipe:2009/05/15/recipe1]"
    assigns[:meals][0]["menu"] << "[recipe:2009/05/15/recipe2]"

    render("/views/index.haml")
    response.should have_selector(".menu-items",
                                  :content => "chips, salsa")
  end

Old recipes and non-recipes should not be included on the homepage:

  it "should only include new recipe menu items" do
    stub!(:recipe_link).
      and_return(%Q|<a href="/recipes/2009/05/15/recipe1">chips</a>|)

    assigns[:meals][0]["menu"] << "[recipe:2009/05/14/recipe1]"
    assigns[:meals][0]["menu"] << "chili"
    assigns[:meals][0]["menu"] << "[recipe:2009/05/15/recipe2]"

    render("/views/index.haml")
    response.should have_selector(".menu-items",
                                  :content => "chips")
  end

No new recipes should produce nothing:

  it "should not include a delimiter between \"Read more\" and new recipes when no new recipes" do
    render("/views/index.haml")
    response.should_not have_selector(".meals",
                                      :content => "|")

  end

I implement these three examples with this Haml code:

    - new_recipe_regexp = Regexp.new(date.strftime("%Y/%m/%d"))
    - new_recipes = meal["menu"].select{ |r| r =~ new_recipe_regexp }
    (
    %a{:href => date.strftime("/meals/%Y/%m/%d")}
      Read more…
    - if new_recipes.length > 0
      |
    .menu-items= wiki(new_recipes.join(", "))
    )

In that code snippet, I store a regular expression built from the meal's current date. I use that regular expression to select all recipes from the menu that match the current date. As long as there are new recipes, a "pipe" delimiter is inserted between the link to the current meal and to the new recipes. Finally, the wiki helper converts the wiki recipe text to HTML links.

I will stop there for today and pick up with the last two missing affordances tomorrow.

There and Back Again: A User's Journey from the Homepage Complete

‹prev | My Chain | next›

The next step in the exploration-from-the-homepage Cucumber scenario is returning back to the homepage. Amazingly, I have made it through three and a half months of my chain without a site-wide layout. That will need to change in order to get this next step passing.

Haml layouts in Sinatra are designated by creating a layout.haml file. The following simple layout should do the trick:

%html
  %title= ["EEE Cooks", @title].compact.join(": ")
%body
  #header
    #eee-header-logo
      %a{:href => "/"}
        %img{:alt => "Home", :src => "/images/eee_corner.png"}

  = yield

  #footer

Before defining the click-logo-to-return-home step, I re-run the whole Cucumber scenario to make sure the layout not break anything. Unfortunately, the earlier step that checked the number of meal thumbnail images on the homepage is now failing:

   When I view the site's homepage
    Then I should see the 10 most recent meals prominently displayed
    And the prominently displayed meals should include a thumbnail image
      expected following output to contain a <img/> tag:
      <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
      <html>
      <head><title>EEE Cooks</title></head>
      <html><body>
        <div id="header">
          <div id="eee-header-logo">
            <a href="/">
              <img alt="Home" src="/images/eee_corner.png"></a>
          </div>
        </div>
        <div class="meals">
          <h1>Meals</h1>
          <a href="/meals/2009/06/11">
            <img height="150" width="200" src="/images/2009-06-11/meal0.jpg"></a>
          <h2>
            <a href="/meals/2009/06/11">Meal 0</a>
          </h2>
          <p>meal summary</p>
...

The thumbnails are still there, so what gives? The failing Cucumber scenario is currently defined as:

Then /^the prominently displayed meals should include a thumbnail image$/ do
  response.should have_selector("img", :count => 10)
end

Ah, rather than verifying that there are 10 meal thumbnail images, I am trying to verify that there are 10 images on the entire homepage. The addition of the site logo has upped the number of images on the homepage to 11. A CSS selector can provide the necessary context to only check meal thumbnails:

Then /^the prominently displayed meals should include a thumbnail image$/ do
  response.should have_selector(".meals img", :count => 10)
end

The additional context in the scenario step gets it passing, so now I can try defining the click-the-logo step:

When /^I click the site logo$/ do
  click_link "/"
end

That link is now on the page, thanks to the newly added layout, so this step is passing.

The next step is simply verifying that the user is back on the homepage after clicking the site logo. At this point, the distinguishing characteristic of the homepage is the inclusion of 10 meal summaries. So I use that to verify this step:

Then /^I should see the homepage$/ do
  response.should have_selector(".meals h2", :count => 10)
end

Now that the user has gone from homepage to meal, to recipe, and back to the homepage, the next step is clicking on the recipe text under the 6^th meal on the homepage. The primary reason for choosing the 6^th meal/recipe was that this was the first that was vegetarian (the first 5 were Italian). Subsequent steps will verify that it behaves like vegetarian recipes should (i.e. the vegetarian category link is highlighted).

In this scenario, each meal has exactly one menu item—a recipe created just for that meal. Recipe names follow an obvious convention such that the recipe for the 6^th meal should be named "Recipe for Meal 5" (meal indexes start at zero). The user should be able to click on the 6^th recipe by clicking that text:

When /^I click the recipe link under the 6th meal$/ do
  click_link "Recipe for Meal 5"
end

The second to last step in this scenario—verifying that the user is now on the recipe page—was already defined. After a small tweak to ensure that it applies for all recipes, I am onto the final step in this scenario, verifying that the vegetarian category is highlighted on this recipe page.

For a previous recipe, I defined a should-have-the-italian-category scenario step:

Then /^the Italian category should be highlighted$/ do
  response.should have_selector("a",
                                :class => "active",
                                :content => "Italian")
end

A quick Regexp rewrite will get that step working for both Italian and vegetarian recipes:

Then /^the (\w+) category should be highlighted$/ do |category|
  response.should have_selector("a",
                                :class => "active",
                                :content => category)
end

And, with that, I am all done with another scenario:



(commit)

With the entire scenario green, I will likely spend some time refactoring before moving onto the next scenario. Tomorrow.

I Can't Believe that I Never Linked

‹prev | My Chain | next›

Today, I continue working my way through the navigation from the home page Cucumber scenario. So far, I have been able to verify that meals are listed on the homepage and that the user can click through the meals onto recipe pages. Next in the scenario is verifying that the user can click on some category links before returning to the home page.

To verify the ability of the user to click on the Italian category on the recipe page, I ought to be able to do something as simple as:

When /^I click on the Italian category$/ do
  click_link "Italian"
end

I ought to be able to do something like that, but...

cucumber -n features \
   -s "Quickly scanning meals and recipes accessible from the home page"
...
    When I click on the recipe in the menu
    Then I should see the recipe page
    And the Italian category should be highlighted
    When I click on the Italian category
      Could not find link with text or title or id "Italian" (Webrat::NotFoundError)
      features/site.feature:23:in `When I click on the Italian category'
...

Hunh. I just spent yesterday DRYing up the category links. Did I mess something up? To answer that question, I'll use Webrat's save_and_open_page helper method to dump a copy of the page to the browser. After adding this to the Cucumber step:

When /^I click on the Italian category$/ do
  save_and_open_page()
  click_link "Italian"
end

I find this in the browser:



Hmmm... the categories, including Italian, are there, but they do not look like normal hyperlinks. Viewing the source, I see:

<ul id="eee-categories">
  <li><a class="active">Italian</a></li>
  <li><a>Asian</a></li>
...

Ah, no href attribute. It would seem that Webrat does not view <a> tags without href attributes as links any more than Firefox does. Ah well, looks as though I have a little more work to do in the code before I can mark this step as complete.

When I click on a category link, such as "Italian", the user should be taken to the list of recipes that fall into that category. Fortunately, I already have a couchdb-lucene search results page that holds this information. To link the categories at the top of the pages to those search results, I start with this RSpec example:

  it "should link to the category search results" do
    recipe_category_link({}, "Italian").
      should have_selector("a",
                           :href => "/recipes/search?q=tag_names:italian")
  end

To get that example to pass, I add href attributes to the recipe_category_link helper:

    def recipe_category_link(recipe, category)
      recipes = recipe.is_a?(Array) ? recipe : [recipe]
      href = "/recipes/search?q=tag_names:#{category.downcase}"
      if recipes.any? { |r|
          r['tag_names'] &&
          r['tag_names'].include?(category.downcase)
        }
        %Q|<a class="active" href="#{href}">#{category}</a>|
      else
        %Q|<a href="#{href}">#{category}</a>|
      end
    end

With that implemented, I work my way back to the Cucumber scenario to find the click-the-category-link step is now passing:



The next step in the scenario verifies that the five Italian recipes created early in the scenario are displayed on the category results page. Something like this ought to suffice:

Then /^I should see 5 Italian recipes$/ do
  # 5 result rows + 1 header row
  response.should have_selector("tr",
                                :count => 6)
end

That scenario step failed at first because I had not been indexing the categories in couchdb-lucene. After addressing that deficiency, I am up to 16 of 21 steps passing:



Hopefully tomorrow, I can finish up the navigation from the home page scenario.

DRYing up the Categories

‹prev | My Chain | next›

I'm on vacation, but the don't-break-the-chain gods recognize no holidays and never spend a day at the beach. Lest they gaze upon me with disfavor, I will continue to do at least a little work each day on my chain to stay in their good graces. I have no idea what the wrath of the don't-break-the-chain gods is like and I do not intend to find out.

I noted last night that the code for the category links at the top of most pages was starting to feel repetitive. On the legacy Rails site, the category links look like:



The "Vegetarian" category is in red to indicate that the user is on a vegetarian meal, recipe, or list.

The new implementation of recipe categories, using Haml, looks like:

%ul#eee-categories
  %li= recipe_category_link(@recipe, 'Italian')
  %li= recipe_category_link(@recipe, 'Asian')
  %li= recipe_category_link(@recipe, 'Latin')
  %li= recipe_category_link(@recipe, 'Breakfast')
  %li= recipe_category_link(@recipe, 'Chicken')
  %li= recipe_category_link(@recipe, 'Fish')
  %li= recipe_category_link(@recipe, 'Meat')
  %li= recipe_category_link(@recipe, 'Salad')
  %li= recipe_category_link(@recipe, 'Vegetarian')
  %li
    %a Recipes

There is much repetition in there—9 calls of the recipe_category_link helper, which is responsible for highlighting the link when appropriate. What's worse is that the following is in the meal Haml template (the above is in the recipe template):

%ul#eee-categories
  %li= recipe_category_link(@recipes, 'Italian')
  %li= recipe_category_link(@recipes, 'Asian')
  %li= recipe_category_link(@recipes, 'Latin')
  %li= recipe_category_link(@recipes, 'Breakfast')
  %li= recipe_category_link(@recipes, 'Chicken')
  %li= recipe_category_link(@recipes, 'Fish')
  %li= recipe_category_link(@recipes, 'Meat')
  %li= recipe_category_link(@recipes, 'Salad')
  %li= recipe_category_link(@recipes, 'Vegetarian')
  %li
    %a Recipes

I have definitely reached the refactor portion of the Red-Green-Refactor behavior driven development cycle. I could DRY the code up by either factoring the duplication out into a shared partial or into a helper. I opt for the helper since recipe_category_link is already a helper—might as well keep them close should any later work need to be done.

The specs for the categories helper end up reading:

categories
- should link to the italian category
- should be able to highlight the link to the italian category
- should link to the fish category
- should link to the vegetarian category
- should link to all recipes

Since there is so much repetition in the the category listing, the individual RSpec examples are all very much the same. The "vegetarian" example reads:

  it "should link to the vegetarian category" do
    categories({}).
      should have_selector("#eee-categories a", :content => "Vegetarian")
  end

The other examples replace "vegetarian" with the appropriate other category.

The categories helper gets driven to:

    def categories(context)
      categories = %w{Italian Asian Latin Breakfast Chicken Fish Meat Salad Vegetarian}

      links = categories.map do |category|
        %Q|<li>#{recipe_category_link(context, category)}</li>|
      end

      links << "<a>Recipes</a>"

      %Q|<ul id="eee-categories">#{links}</ul>|
    end

Finally, I replace the repetitive Haml code with a single call to the new categories helper. I make sure to run all of my specs and then call it a night.
(commit)

Marking Meal to Recipe Navigation as Complete

‹prev | My Chain | next›

Before moving on to "real" work, I run all of my tests only to find that I have several errors. There are many errors in the meal.haml_spec.rb specification:

11)
NoMethodError in 'meal.haml should wikify the meal's description'
undefined method `[]' for nil:NilClass
./helpers.rb:18:in `recipe_category_link'
(haml):39:in `any?'
./helpers.rb:17:in `each'
./helpers.rb:17:in `any?'
./helpers.rb:17:in `recipe_category_link'
(haml):2:in `render'
/home/cstrom/.gem/ruby/1.8/gems/haml-2.0.9/lib/haml/engine.rb:149:in `render'
/home/cstrom/.gem/ruby/1.8/gems/haml-2.0.9/lib/haml/engine.rb:149:in `instance_eval'
/home/cstrom/.gem/ruby/1.8/gems/haml-2.0.9/lib/haml/engine.rb:149:in `render'
/home/cstrom/repos/eee-code/spec/spec_helper.rb:27:in `render'
./spec/views/meal.haml_spec.rb:86:

All eleven errors are caused by the inclusion of the recipe_category_link helper last night. I am not able to stub out the method, so I seed some dummy data in the before(:each) block to eliminate the errors:

    assigns[:recipes] = []

This prevents the recipe_category_link from acting upon a nil @recipes array when building the category links:

%ul#eee-categories
  %li= recipe_category_link(@recipes, 'Italian')
  %li= recipe_category_link(@recipes, 'Asian')
...

Next up, it is back to the Cucumber scenario. Specifically, I need to mark a few scenario steps as complete in the navigation-from-the-homepage Cucumber scenario. Yesterday, I was able to verify that a user could navigate from the homepage to a recent meal. I also ensured that site-wide categories were displaying on the same meal page.

Now, I need to ensure that the user can navigate from the meal down to a recipe listed on the menu. Cucumber tells me that I can implement the missing steps with:

When /^I click on the recipe in the menu$/ do
  pending
end

Then /^I should see the recipe page$/ do
  pending
end

As mentioned, the scenario so far involves clicking on the most recently prepared meal, then clicking on the recipe on that meal's menu. The meals created for this scenario have titles: "Meal 0", "Meal 1", "Meal 2", etc. In turn, the recipes for each meal are named simply: "Recipe for Meal 0", "Recipe for Meal 1", "Recipe for Meal 2", etc. So, to click on the recipe for the first meal, I need to look for a link to "Recipe for Meal 0":

When /^I click on the recipe in the menu$/ do
  click_link "Recipe for Meal 0"
end

Similarly, to verify that I am on the appropriate recipe page, I check the <h1> tag:

Then /^I should see the recipe page$/ do
  response.should have_selector("h1",
                                :content => "Recipe for Meal 0")
end

The next step in the scenario, that the Italian category should be highlighted for this Italian recipe, was implemented last night. The step was written for the meal (the meal is Italian because it has an Italian recipe on the menu), but applies to category links on the recipe page just as it does on the meal page.

And just like that, I am done with 14 of the 21 steps in the scenario:



Before moving onto the next steps, I think there are some DRY violations in the category links that I need to address. Tomorrow.

Categorizing Meals

‹prev | My Chain | next›

The next couple of items in the navigation-from-the-homepage Cucumber involve clicking through to a meal:



The next undefined step is "When I click on the first meal". Hmm... I think I forgot to link to the meals from the homepage. Looking closer I find an example that superficially describes linking to meals, but actually only verifies that it includes the title text:

  it "should link to the meal titles" do
    render("/views/index.haml")
    response.should have_selector("h2", :content => "Bar")
  end

I rename that example as "should include meal titles". Then I create the real example for linking to meals:

  it "should link to the the meal titles" do
    render("/views/index.haml")
    response.should have_selector("a",
                                  :href => "/meals/2009/05/15",
                                  :content => "Bar")
  end

Once I get that passing by adding the appropriate %a Haml tag, it is time to move back to the Cucumber scenario. I can mark the next two steps as passing at this point. I can both click a meal link and verify that I am on the meal page:

When /^I click on the first meal$/ do
  click_link "Meal 0"
end

Then /^I should see the meal page$/ do
  response.should have_selector("h1",
                                :content => "Meal 0")
end

Those two steps pass, putting me half way through the exploration-from-the-homepage scenario:



The next "then" step states that "the Italian category should be highlighted". I already have something similar for the recipe page:

%ul#eee-categories
  %li= recipe_category_link(@recipe, 'Italian')
  %li= recipe_category_link(@recipe, 'Asian')
...

To determine if a meal is Italian, each of the recipes on the menu need to be checked. If any of them are Italian, then the meal will be considered Italian. So I'll need to load the recipes and I'll need to update the recipe_category_link to handle more than one recipe.

First up, loading a recipe from wiki text. For text similar to "[recipe:2009/06/16]", CouchDB should be queried and the results parsed:

describe "wiki_recipe" do
  before(:each) do
    @json = '{"_id":"2009-06-16-recipe","title":"Recipe for Foo"}'
  end
  it "should lookup a recipe from recipe wiki text" do
    RestClient.
      should_receive(:get).
      with(/2009-06-16/).
      and_return(@json)

    wiki_recipe(" [recipe:2009/06/16]")
  end
  it "should return a recipe from recipe wiki text" do
    RestClient.
      stub!(:get).
      and_return(@json)

    wiki_recipe(" [recipe:2009/06/16]").
      should == { "_id" => "2009-06-16-recipe",
                  "title" => "Recipe for Foo" }

  end
  it "should return nil for non-recipe wiki text" do
    wiki_recipe("[rcip:2009/06/16]").should be_nil
  end
end

I can make those three examples pass with:

    def wiki_recipe(text)
      if text =~ /\[recipe:([-\/\w]+)/
        permalink = $1.gsub(/\//, '-')
        JSON.parse(RestClient.get("#{_db}/#{permalink}"))
      end
    end

When viewing a meal, I load all recipes into an instance variable in the Sinatra app:

  @recipes = @meal['menu'].map { |m| wiki_recipe(m) }.compact

With the Sinatra app using wiki_recipe to lookup recipes, I need to get recipe_category_link to use multiple recipes to determine whether or not to highlight category links. The example uses two "recipes", one with an "italian" category, which should highlight the link:

  it "should create an active link if any recipes include the category" do
    recipes = [{ 'tag_names' => ['italian'] },
               { 'tag_names' => ['foo'] }]
    recipe_category_link(recipes, 'Italian').
      should have_selector("a", :class => "active")
  end

I make that example pass (while keeping the existing, non-array examples passing) with:

    def recipe_category_link(recipe, category)
      recipes = recipe.is_a?(Array) ? recipe : [recipe]
      if recipes.any? { |r|
          r['tag_names'] &&
          r['tag_names'].include?(category.downcase)
        }
        %Q|<a class="active">#{category}</a>|
      else
        %Q|<a>#{category}</a>|
      end
    end

I then use the new recipe_category_link and the @recipes instance variable assigned in the Sinatra application to build category links in the meal Haml template:

%ul#eee-categories
  %li= recipe_category_link(@recipes, 'Italian')
  %li= recipe_category_link(@recipes, 'Asian')
  %li= recipe_category_link(@recipes, 'Latin')
  %li= recipe_category_link(@recipes, 'Breakfast')
  %li= recipe_category_link(@recipes, 'Chicken')
  %li= recipe_category_link(@recipes, 'Fish')
  %li= recipe_category_link(@recipes, 'Meat')
  %li= recipe_category_link(@recipes, 'Salad')
  %li= recipe_category_link(@recipes, 'Vegetarian')
  %li
    %a Recipes

Finally, with that in place, I work back out to the Cucumber scenario. Implementing the Italian-category-should-be-highlighted step:

Then /^the Italian category should be highlighted$/ do
  response.should have_selector("a",
                                :class => "active",
                                :content => "Italian")
end

And now, I am one step closer to being done with this scenario:


(commit)

Astute readers will note that the recipe_category_link omits the href attribute. It is not much of a link without that attribute. Fortunately, subsequent steps in this scenario cover this omission. Something for another day.

Homepage Navigation

‹prev | My Chain | next›

Today, I continue working on the navigation from the homepage Cucumber scenario. I implemented view code to present meal and recipe information last night. I was able to mark one more step in the scenario as complete. Tonight I need to ensure that the homepage is displaying recipe links (as it should after yesterday's effort). The step that will verify that things are working as desired:

Then /^the prominently displayed meals should include the recipe titles$/ do
  response.should have_selector(".menu-items",
                                :content => "Recipe for Meal 1")
end

When I run the scenario, however, I find:

cstrom@jaynestown:~/repos/eee-code$ cucumber -n features \
    -s "Quickly scanning meals and recipes accessible from the home page"
Sinatra::Test is deprecated; use Rack::Test instead.
Feature: Site

  So that I may explore many wonderful recipes and see the meals in which they were served
  As someone interested in cooking
  I want to be able to easily explore this awesome site

  Scenario: Quickly scanning meals and recipes accessible from the home page
    Given 25 yummy meals
    And 1 delicious recipe for each meal
    And the first 5 recipes are Italian
    And the second 10 recipes are Vegetarian
    When I view the site's homepage
      Resource not found (RestClient::ResourceNotFound)
      /usr/lib/ruby/1.8/net/http.rb:543:in `start'
      ./helpers.rb:41:in `recipe_link'
      ./helpers.rb:27:in `wiki'
      ./helpers.rb:27:in `gsub!'
      ./helpers.rb:27:in `wiki'
      /home/cstrom/repos/eee-code/views/index.haml:7:in `render'
      /home/cstrom/repos/eee-code/views/index.haml:3:in `each'
      /home/cstrom/repos/eee-code/views/index.haml:3:in `render'
      ./features/support/../../eee.rb:30:in `GET /'
      (eval):7:in `get'
      features/site.feature:13:in `When I view the site's homepage'

Hmm... A RestClient error—time to check the CouchDB log, where I see:

[info] [<0.24918.15>] 127.0.0.1 - - 'GET' /eee-test/2009/06/11/recipe 404

Ah, somehow I am requesting the wrong URL. I ought to be requesting the ID from the DB, not a nested resource as I have done here. Specifically, I should be looking for /eee-test/2009-06-11-recipe. So where am I going wrong?

The request is being made by the wiki helper, which, in turn, uses the recipe_link helper to convert wiki text like [recipe:2009/06/11/recipe] into links to the recipe page—by looking the recipe up in the CouchDB database. In the current Cucumber scenario, I am generating wiki text with slashes (as I think I did in the legacy application). I have the feeling that, when I coded the helper in the first place, I accounted only for explicit IDs (e.g. 2009-06-11-recipe).

So it is back into the helper specification to add this example:

  it "should be able to link with \"slash\" dates (e.g. 2009/06/11/recipe)" do
    RestClient.
      should_receive(:get).
      with(/2009-06-11-recipe/).
      and_return(@json)

    recipe_link("2009/06/11/recipe")
  end

I am testing implementation details here rather than behavior. Should I ever change from RestClient to CouchRest, I will have to return here to update the spec—even though no behavior will change. I accept this as the price to keeping my unit tests at the unit level. Hopefully I will not be changing CouchDB client libraries often.

At any rate, this example can drive change in the actual code. This version of the recipe_link helper will work with links with slashes or dashes:

    def recipe_link(link, title=nil)
      permalink = link.gsub(/\//, '-')
      recipe = JSON.parse(RestClient.get("#{_db}/#{permalink}"))
      %Q|<a href="/recipes/#{recipe['_id']}">#{title || recipe['title']}</a>|
    end

I can now move back out to the Cucumber scenario to see where I am at:



Happily, where I am at is done with another step. Up next, I will move onto the next step which moves off the homepage as the "user" explores the site.