4

I have two unit tests that should share a lot of common tests with slightly different setup methods. If I write something like

class Abstract < Test::Unit::TestCase
  def setup
    @field = create
  end

  def test_1
    ...
  end
end

class Concrete1 < Abstract
  def create
    SomeClass1.new
  end
end

class Concrete2 < Abstract
  def create
    SomeClass2.new
  end
end

then Concrete1 does not seem to inherit the tests from Abstract. Or at least I cannot get them to run in eclipse. If I choose "Run all TestCases" for the file that contains Concrete1 then Abstract is run even though I do not want it to be. If I specify Concrete1 then it does not run any tests at all! If I specify test_1 in Concrete1 then it complains it cannot find it ("uncaught throw :invalid_test (ArgumentError)").

I'm new to Ruby. What am I missing here?

Andrew Grimm
  • 78,473
  • 57
  • 200
  • 338
Graeme Moss
  • 7,995
  • 4
  • 29
  • 42

2 Answers2

7

The issue is that, as far as I can tell, Test::Unit keeps track of which classes inherit from Test::Unit::TestCase, and as a result, will only run tests from classes that directly inherit from it.

The way to work around this is to create a module with the tests you want, and then include that module in the classes that derive from Test::Unit::TestCase.

require 'test/unit'

module TestsToInclude
  def test_name
    assert(self.class.name.start_with?("Concrete"))
  end
end

class Concrete1 < Test::Unit::TestCase
  include TestsToInclude

  def test_something_bad
    assert(false)
  end
end

class Concrete2 < Test::Unit::TestCase
  include TestsToInclude

  def test_something_good
    assert(true)
  end
end

Output:

Loaded suite a
Started
.F..
Finished in 0.027873 seconds.

  1) Failure:
test_something_bad(Concrete1) [a.rb:13]:
<false> is not true.

4 tests, 4 assertions, 1 failures, 0 errors

shell returned 1
Mark Rushakoff
  • 249,864
  • 45
  • 407
  • 398
  • Thanks - this is great! It helped me finally solve http://stackoverflow.com/questions/8888614/how-to-write-and-inherit-from-an-abstract-subclass-of-actioncontrollertestcase which is set in the context of Rails functional (controller) tests, and as such has a little extra challenge. – Adam Spiers Jan 26 '12 at 00:24
  • One other observation: unfortunately it seems that this approach does not allow overriding of the included tests. I guess another hack will be needed to work around that :-( – Adam Spiers Jan 26 '12 at 00:37
  • 1
    That doesn't make sense to me. If test classes must directly inherit from Test::Unit::TestCase, how do ActiveSupport::TestCase and ActionController::TestCase not cause the problem described in this question? Aren't they both just additional levels of inheritance between Test::Unit::TestCase and the concrete classes? – Isaac Betesh Oct 10 '12 at 19:52
2

The problem is that Test::Unit::TestCase explicitly doesn't run tests defined in superclasses by default. In particular, note that TestSuiteCreator does not run tests unless Test::Unit::TestCase#valid? returns true (https://github.com/test-unit/test-unit/blob/2.5.5/lib/test/unit/testsuitecreator.rb#L40):

def append_test(suite, test_name)
  test = @test_case.new(test_name)
  yield(test) if block_given?
  suite << test if test.valid?
end

And what determines if a test case is valid? A test case is valid by default if the this class explicitly defined that method, or if the method was defined in a Module (https://github.com/test-unit/test-unit/blob/2.5.5/lib/test/unit/testcase.rb#L405-L418):

def valid? # :nodoc:
  return false unless respond_to?(@method_name)
  test_method = method(@method_name)
  if @internal_data.have_test_data?
    return false unless test_method.arity == 1
  else
    return false unless test_method.arity <= 0
  end
  owner = Util::MethodOwnerFinder.find(self, @method_name)
  if owner.class != Module and self.class != owner
    return false
  end
  true
end

So basically, if you subclass another unit test class, and you want to run the superclass's unit tests, you can either:

  • Redefine those test methods in your subclass and have them call your superclass's test method
  • Move all your methods to a module (as explained in the other answer in this thread)
  • Redefine the valid? method in your subclass to return true:

def valid? return true end

Ben Nham
  • 21
  • 2