21

What's the best way to have a setup run before every method in an entire test suite (not just one test class)?

Rspec allows you to define global before and after blocks. Is there a clean comparable way to do this in Test::Unit that doesn't involve mixing a module into each test class?

Andrew Grimm
  • 78,473
  • 57
  • 200
  • 338
samg
  • 3,496
  • 1
  • 25
  • 26
  • I'm also really interested in this. I'm using mongoid with cucumber and all of the examples to clear the db between tests use Rspec. I don't really like the solution below as it doesn't allow me to also have individual setup/teardown methods in each test, along with a global one. – brad Aug 30 '10 at 11:58
  • possible duplicate of [In Ruby's Test::Unit::TestCase, how do I override the initialize method?](http://stackoverflow.com/questions/255969/in-rubys-testunittestcase-how-do-i-override-the-initialize-method) – Andrew Grimm Oct 11 '11 at 23:06

2 Answers2

24

Assuming you're using Rails. Just add following in your test/test_helper.rb file.

class ActiveSupport::TestCase
  setup :global_setup

  def global_setup
    #stuff to run before _every_ test.
  end
end

Tested on Rails 3.0.9.

Vikrant Chaudhary
  • 11,089
  • 10
  • 53
  • 68
  • Is there a way to make sure the local setup method is called first? – Isaac Betesh Sep 25 '12 at 01:36
  • @IsaacBetesh Nope, I don't think so. But, I'm pretty sure that you can find a workaround in your code as this is a pretty standard way of chaining - "common setup before local setup". (Though I'm not selling that as a "fact", I'm just saying that it is more of a rule than an exception; and there can be counter examples). – Vikrant Chaudhary Sep 25 '12 at 09:50
7

You could just patch Test::Unit::TestCase and define a setup method:

class Test::Unit::TestCase
  def setup
    puts 'in setup'
  end
end

And your subclasses would just use this by default:

class FooTest < Test::Unit::TestCase
  def test_truth
    assert true
  end
end

class BarTest < Test::Unit::TestCase
  def test_truth
    assert true
  end
end

If a test case needed to have its own setup, you would need to call super first to ensure that the global setup runs:

class BazTest < Test::Unit::TestCase
  def setup
    super
    puts 'custom setup'
  end

  def test_truth
    assert true
  end
end

Is having a global setup really something you need to do, or would it be helpful to have a helper method defined on Test::Unit::TestCase and call that in the tests that need it? The helper method approach is something that I find beneficial on my projects – the setup state and intention is clearer in each individual test and I don't need to jump around to find some "hidden" setup method. Quite often, a global setup is a code smell indicating that you need to rethink part of your design, but YMMV.

Update

Since you're using ActiveSupport, here's a first stab at something that won't require a call to super each time you define a setup method in your test case. I don't know how valuable it is, since it requires a call to a different method and any developer can just define their own setup method in the test case that will invalidate this change. Here it is:

require 'rubygems'
require 'test/unit'
require 'active_support'
require 'active_support/test_case'

class ActiveSupport::TestCase

  def setup_with_global
    puts 'In Global setup'
    setup_without_global
  end

  alias_method_chain :setup, :global

end

class FooTest < ActiveSupport::TestCase

  def setup_without_global
    puts 'In Local setup'
  end

  def test_truth
    assert true
  end

end
Patrick Reagan
  • 910
  • 7
  • 7
  • In this project it's necessary to clear some global memory caches, so that test cases don't pollute each other. I agree in general that this is a bit of a smell, but IMO it makes more sense here than requiring developers to remember to call a helper, and dealing with the sometime unpredictable consequences. I'm wondering if there's someway to avoid having to call super in each subclass that defines a setup. Does ActiveSupport::TestCase provide this feature with its setups/teardowns? – samg Nov 15 '09 at 18:53
  • I added to the original response - not sure if that solution gets you any closer. – Patrick Reagan Nov 16 '09 at 02:21
  • Without a doubt the best solution is to use the 'super' approach. Do not use alias_method_chain. – Tim Harper Aug 11 '11 at 23:00