Smoke Tests

‹prev | My Chain | next›

Today, I need to do a little smoke testing.

You see, I have looked at my Sinatra application approximately one time during the 4 months that I have been working on it. I have made all progress to date relying on unit tests and Cucumber scenarios. The closest I have come to a browser in that time has been Webrat.

Now that I have 1,000+ recipes and meals loaded from my legacy application, it's time to see how things work in live conditions.

To be clear, I expect a few minor problems. My testing should have caught the big stuff and most of the little stuff. But tests seem to rely on idealized data that does not necessarily show up in live data. The thing I almost always do is expect a number when the actual value is a string (or vice versa). Let's see how well I did avoiding that little trap...



With naked CSS, the links to the recipe categories force everything else on the homepage "below the fold" (out of the view port). This makes the most obvious thing to explore first in my smoke test the categories:



No results?! Oh, man! I spent a lot of time getting couchdb-lucene working, including integration tests. How did I mess that up? My smoke testing is off to a poor start.

It turns out that the load from the legacy Rails application completely missed categories (tag_names). All that is needed is a small addition to Recipe class:

class Recipe < ActiveRecord::Base
  def tag_names; tags.map(&:name) end
end

(I updated last night's instructions so that I do not forget in the future).

With that, I rake couchdb:reset and re-run the legacy data load (all 1,000+ documents). Then, reloading the search results page for breakfast recipes, I find:



Yay!

Having spent the better part of four months working on this, it is pretty exciting to actually use the application with real data in it. Sorting works. Pagination works. I ought to expect it to work, what with all of the unit and integration/Cucumber tests, but there is something about using it in an actual browser that gives a little thrill.

That thrill is tempered by two things:

• the search field is not displayed (it was shown when no results were found)
• there is a weird character displayed in the "Next" link of the pagination

I make a note of the missing search field by adding it to a Cucumber scenario:

    Scenario: Matching a word in the ingredient list in full recipe search

      Given a "pancake" recipe with "chocolate chips" in it
      And a "french toast" recipe with "eggs" in it
      And a 0.5 second wait to allow the search index to be updated
      When I search for "chocolate"
      Then I should see the "pancake" recipe in the search results
      And I should not see the "french toast" recipe in the search results
      And I should see the search field for refining my search

The weird character (at the bottom):



The weird character is just an encoding issue caused by including UTF-8 directly in the pagination helper:

      links <<
        if current_page == last_page
          %Q|<span class="inactive">Next »</span>|
        else
          %Q|<a href="#{link}&page=#{current_page + 1}">Next »</a>|
        end

I am not sure why I included the actual double right angle quote in there rather than an HTML entity (I used the HTML entity in the Previous links). At any rate, replacing "»" with "»" resolves the issue:



No test changes are required because Webrat is HTML entity aware—it knows that "»" and "»" are the same thing.

Aside from the minor issues with the recipe search (which were mostly caused by a bad load from the legacy application) I do not hit any more issues in my cursory smoke test. From the recipe, I can navigate back up the breadcrumbs to meals, then lists of meals by month, lists of meals by year and then back to the homepage.

Not even a string that is treated as an integer?! This time, it would seem not.

Up tomorrow: I will likely smoke test tomorrow a bit more (seriously, I must have something buggy in there). I will also note a few more features that I am missing.