Development Blog: Viget Labs

David Eisinger, Web Developer, June 19, 2009 5

If you aren’t using Autotest to develop your Ruby application, you’re missing out on effortless continuous testing. If you’d like to be using Autotest, but can’t get it running properly, I’ll show you how to set it up.

Autotest is a fantastic way to do TDD/BDD. Here’s a rundown of the benefits from the project homepage:

• Improves feedback by running tests continuously.
• Continually runs tests based on files you’ve changed.
• Get feedback as soon as you save. Keeps you in your editor allowing you to get stuff done faster.
• Focuses on running previous failures until you’ve fixed them.

Continue reading "How (& Why) to Run Autotest on your Mac"

Justin Marney, Web Developer, May 26, 2009 1

Last month David wrote up a good explanation of how to create shoulda macros with blocks. Recently, I needed to reuse context behavior across a few different tests as well. Out of curiosity, I went in search of a more idiomatic solution and was able to find this ticket and its associated conversation. From the discussion surrounding that ticket, I learned that you can use the merge_block method to create nestable context macros.

class Test::Unit::TestCase
  def self.context_with_an_object(&block)
    context "With an object" do
      setup do
        @object = {:rock => 'on'}
      end

      should "do something fantastic" do
        assert @object[:rock], 'on'
      end

      merge_block(&block) if block_given?
    end
  end
end

You can use the context macro in one of your tests and it will accept a block as well as respect context nesting.

class ModelTest < Test::Unit::TestCase
  context "A great and wonderous test" do
    setup do
      @thing = {:creature => 'lagoon', :rock => 'on'}
    end

    context_with_an_object do
      should "do something specific" do
        assert_equal @thing[:rock], @object[:rock]
      end

      context "And a friend" do
        setup do
          @friend = {:rock => 'on'}
        end

        should "respect some nested context insanity" do
          assert_equal @friend[:rock], @thing[:rock]
        end
      end
    end
  end
end

You can also create your context macros such that they accept arguments.

class Test::Unit::TestCase
  def self.context_with_a_modified_object(modifier, &block)
    context "with a modified object" do
      setup do
        @object = {:mod => modifier}
      end

      merge_block(&block) if block_given?
    end
  end
end

Modifying the context behavior via an argument allows you to test a handful of edge cases without having to duplicate context code.

class ModelTest < Test::Unit::TestCase
  context_with_a_modified_object("dance!") do
    should "be modified" do
      assert_equal @object[:mod], "dance!"
    end
  end
end

I recommend using this technique sparingly and only to remove unnecessary duplication among your tests. It is possible to hide too much context behavior behind these macros and end up with tests that are difficult to understand and maintain. For contexts that aren't reused outside of a single file consider defining them at the top of the test file.

Tony Pitale, Web Developer, May 04, 2009 3

In my introductory post, I explained what Garb was, and how it could be useful to those wishing to get access to their Google Analytics data. In this post, I would like to introduce the latest version of Garb (0.2.1 as of this writing) and explain the many changes and new ways to use Garb to get at your data.

Getting sessions and profiles is still exactly the same.

  Garb::Session.login('username', 'password')
  profile = Garb::Profile.all.first

What's new in 0.2.1 is the way in which reports are built and results are retrieved. Check it out:

As a Report Class

  class Exits
    include Garb::Resource

    metrics :exits, :exit_rate
    dimensions :request_uri
  end

Getting the Results with a Class

  Exits.results(profile, :limit => 10,
                         :offset => 20,
                         :start_date => (Date.today - 30),
                         :end_date => Date.today)

  # With Filtering and Sorting

  Exits.results(profile) do
    filter :request_uri.contains => 'fun', :exits.gte => 1000
    sort :exit_rate
  end

One-off Report

  report = Garb::Report.new(profile)
  report.metrics :exits, :exit_rate
  report.dimensions :request_uri

  # With Filtering and Sort

  report.filter :request_uri.contains => 'fun'
  report.filter :exits.gte => 1000
  report.sort :exit_rate.desc

  # Getting Results

  report.results(:limit => 10,
                 :offset => 20,
                 :start_date => (Date.today - 30),
                 :end_date => Date.today)

The results returned from Garb will be OpenStructs with methods for each of the metrics and dimensions in an array.

  results.exits       #=> 1234
  results.exit_rate   #=> 0.20423810234
  results.request_uri #=> '/some/fun/url/to/a/page'

Overall, we feel that the improvements are solid and make more sense. Be warned: if you've used a previous version of Garb, then updating to the latest version will very likely break most of what was done previously. I hope everyone can find a use for this, and I encourage all to check out the project on Github and to read the documentation in the Wiki.

Patrick Reagan, Development Director, March 26, 2009 1

I have been interested in finding an effective way to use gitjour to share code with others during hack night gatherings, but I never really sat down to figure out the correct workflow. Until last night, that is.

At the Potomac Hackers meeting, David and I decided that we were going to collaborate on something that involved Sinatra, CouchDB, and the DataMapper CouchDB adapter. We didn't get to work on any of those things, but we did make some progress toward gitjour mastery. Here's what we did:

Continue reading "Adding Gitjour to Your Hack Night Toolset"

Patrick Reagan, Development Director, February 24, 2009 6

I've generated redirects in Apache using mod_rewrite so many times, I can do it in my sleep. Unfortunately, I think I have done them in my sleep. The result? Time wasted chasing down unexpected application behavior and the wrath of the Viget development team.

When a recent re-launch brought with it a change to the Information Architecture of the site, I was determined not to repeat the mistakes of the past. Though this site isn't a Rails application, I wanted to use familiar tools to automate the verification of the rewrite rules I was about to create. In thinking about this a bit more, it was clearly a "behavior-driven" approach - I was specifying the behavior of the web server before its implementation.

Continue reading "Test Drive mod_rewrite Rules With Test::Unit"