Adding setup and teardown to RubyUnit Test Suite

The tests for pvn raise an interesting question to me. The pvn subcommands that wrap/extend the svn subcommands process the svn output, so the tests need svn output to run.

I’ve considered doing mock objects for svn, but that became confounding, where I was essentially mocking all of the svn subcommands that I need. So I’m leaning in the direction of doing operations against a “real” Subversion repository. On a 234M Subversion repository, it takes around 0.4 seconds to do a backup (cp -r), when both the source and the target locations are on the SSD in my machine.

So it’s feasible for the test sequence to be:

• back up the svn repository (0.4 seconds)
• check out the svn repository checked out to working copy (4 seconds)
• working copy modified, with added, changed and deleted files and directories (< 10 seconds for all tests)
• svn repository restored to backed up version (1 second)

I’m still considering how to go about this, but in the meantime I’ve written the following for adding suite-wide setup and teardown for the pvn base testcase. Note that this is on a class:

require 'runit/testcase'

module PVN
  class TestCase < RUNIT::TestCase
    include Loggable

    WIQUERY_DIRNAME = "/Programs/wiquery/trunk"

    class << self
      def setup
        @@orig_location = Pathname.pwd
      end

      def teardown
        Dir.chdir @@orig_location
      end

      def suite
        @@cls = self

        ste = super

        def ste.run(*args)
          @@cls.setup
          super
          @@cls.teardown
        end
        ste
      end
    end

Project pvn

pvn, here on GitHub, is my newest project, a front-end to the Subversion command-line program “svn”. This program will unite my various svn programs, such as svndelta, and my various scripts.

I’ve been building it from scratch, with a core of commands wrapping those in svn, and new commands. At this point the only more-or-less fully working subcommand is log, which extends svn log to use “relative revisions” (explained below), and displays colorized output. I plan to add the functionality so that a user can set the format and colors for log output.

What is probably the most innovative functionality in pvn is that revisions may be “relative”, meaning that +N is the Nth revision, and -N is the Nth revision before the most recent one. In a large project, revision numbers can get into the six and seven digits, and it’s much easier to think of “the latest checkin I did”, as opposed to “my checkin with revision 317127″.

I don’t have a timeline, but my goal is to have the functionality of the log and diff subcommands implemented by the end of the year.