Using strategy pattern in ruby unit testing

Question

Let me begin by admitting that I am ordinarily a Java programmer, but I am trying to learn ruby.

I'm using Ruby 1.9.3 and have installed the test-unit gem (I couldn't figure out how to create test suites using minitest).

I have two classes (call them A and B) which are intended to support the same API, however, they are backed by different data stores (for the sake of argument, filesystem vs database).

Since they support the same API, I would like to write a single collection of tests, but have the collection run against both class A and class B.

In Java, I would create three test classes:

• AbstractTest : which would list all the test methods, and have an abstract method getTestee() whose implementation is expected to return an instance of either class A or class B. Each of the test methods would call getTestee() and then perform its test on the object returned.

• ATest : which would extend AbstractTest, and implement getTestee() returning an instance of class A.

• BTest : which would extend AbstractTest, and implement getTestee() returning an instance of class B.

When I build a similar test class hierarchy in ruby however, the test framework appears to create instances of AbstractTest and not ATest or BTest. AbstractTest doesn't define getTestee() so I get a

NoMethodError: undefined method `getTestee' for test_list(AbstractTest):AbstractTest

Anyway, one of my co-workers has suggested a strategy where I appear to redefine the AbstractTest class and add the getTestee method after-the-fact. Something like:

require 'tests/abstract_test'

require 'a'

class AbstractTest
  def getTestee
    A.new
  end
end

and

require 'tests/abstract_test'

require 'b'

class AbstractTest
  def getTestee
    B.new
  end
end

But this really confuses me and seems like a code smell. It feels like I now have three different AbstractTest classes and no way to refer to them individually inside a TestSuite.

So, what is ruby's generally accepted testing practice for this situation?

Peter.

Answer 1

What I would do is create a base module with all the tests you want to run, and then initialize the objects in your derived classes. Something like this (using Ruby's built-in Test::Unit library):

module Testers
  def test_something
    assert_equal "expected result", @myobject.function_call
  end

  # ....
end

Then later on your actual test classes:

require 'test/unit'

class TestA < Test::Unit::TestCase
  def setup
    @myobject = A.new
  end

  include Testers
end

class TestB < Test::Unit::TestCase
  def setup
    @myobject = B.new
  end

  include Testers
end

The magic here is that using a mixin (combination of a module and include) you can have some of the nice aspects of multiple inheritance without actually having multiple inheritance.