The maze book for programmers!

Algorithms, circle mazes, hex grids, masking, weaving, braiding, 3D and 4D grids, spheres, and more!

DRM-Free Ebook

The Buckblog

assorted ramblings by Jamis Buck

TestUnit Inheritance Hierarchies

28 February 2006 — 1-minute read

One of the current design features of Ruby’s TestUnit class is that every subclass of TestUnit must have at least one test method implemented. If that isn’t the case, you get a runtime error.

Sometimes, however, you’d like to use inheritance to set up a hierarchy of test “helpers”. For instance, you’d like to have some scaffolding to aid in integration testing, and you just want to inherit from IntegrationTest to make that scaffolding available.

In those cases, your superclass (IntegrationTest, in this case) simply needs to redefine the run method as follows:

class IntegrationTest < Test::Unit::TestCase
  def run(*args)
    return if @method_name == :default_test

The redefinition of run as given above simply makes it so that the test/unit runners do not try to do anything with empty TestCase subclasses that extend IntegrationTest. I could now, for instance, have subclasses of IntegrationTest, without having to define bogus test methods in IntegrationTest.

Reader Comments

Actually, I remember Nathaniel saying you could just redefine @default_test@ as an empty method:
Ryan, you can definitely do that. The downside of that approach is that it counts as a test in the stats that are generated at the end, so even if you have no "real" tests, the output would show that 1 test was run. The benefit of the approach I described above is that if a testcase has no tests, the emitted statistics would show that 0 tests were run.