В Ruby Test:: Unit:: TestCase, как мне переопределить метод initialize?

Ответ 1

Как упоминалось в книге Хэла Фултона "Рубиновый путь". Он переопределяет self.suite метод Test:: Unit, который позволяет тестовым примерам в классе работать как набор.

def self.suite
    mysuite = super
    def mysuite.run(*args)
      MyTest.startup()
      super
      MyTest.shutdown()
    end
    mysuite
end

Вот пример:

class MyTest < Test::Unit::TestCase
    class << self
        def startup
            puts 'runs only once at start'
        end
        def shutdown
            puts 'runs only once at end'
        end
        def suite
            mysuite = super
            def mysuite.run(*args)
              MyTest.startup()
              super
              MyTest.shutdown()
            end
            mysuite
        end
    end

    def setup
        puts 'runs before each test'
    end
    def teardown
        puts 'runs after each test'
    end 
    def test_stuff
        assert(true)
    end
end

Ответ 2

Как он должен работать!

Каждый тест должен быть полностью изолирован от остальных, поэтому методы setup и tear_down выполняются один раз для каждого тестового случая. Однако есть случаи, когда вам может потребоваться больше контроля над потоком выполнения. Затем вы можете сгруппировать тестовые файлы в сюиты.

В вашем случае вы можете написать что-то вроде следующего:

require 'test/unit'
require 'test/unit/ui/console/testrunner'

class TestDecorator < Test::Unit::TestSuite

  def initialize(test_case_class)
    super
    self << test_case_class.suite
  end

  def run(result, &progress_block)
    setup_suite
    begin
      super(result, &progress_block)      
    ensure
      tear_down_suite
    end
  end

end

class MyTestCase < Test::Unit::TestCase

  def test_1
    puts "test_1"
    assert_equal(1, 1)
  end

  def test_2
    puts "test_2"
    assert_equal(2, 2)
  end

end

class MySuite < TestDecorator

  def setup_suite
    puts "setup_suite"
  end

  def tear_down_suite
    puts "tear_down_suite"
  end

end

Test::Unit::UI::Console::TestRunner.run(MySuite.new(MyTestCase))

TestDecorator определяет специальный набор, который предоставляет методы setup и tear_down, которые запускаются только один раз до и после запуска набора тестовых файлов, которые он содержит.

Недостатком этого является то, что вам нужно сообщить Test:: Unit, как выполнять тесты в блоке. Если ваш блок содержит много тестовых случаев, и вам нужен декоратор только для одного из них, вам понадобится что-то вроде этого:

require 'test/unit'
require 'test/unit/ui/console/testrunner'

class TestDecorator < Test::Unit::TestSuite

  def initialize(test_case_class)
    super
    self << test_case_class.suite
  end

  def run(result, &progress_block)
    setup_suite
    begin
      super(result, &progress_block)      
    ensure
      tear_down_suite
    end
  end

end

class MyTestCase < Test::Unit::TestCase

  def test_1
    puts "test_1"
    assert_equal(1, 1)
  end

  def test_2
    puts "test_2"
    assert_equal(2, 2)
  end

end

class MySuite < TestDecorator

  def setup_suite
    puts "setup_suite"
  end

  def tear_down_suite
    puts "tear_down_suite"
  end

end

class AnotherTestCase < Test::Unit::TestCase

  def test_a
    puts "test_a"
    assert_equal("a", "a")
  end

end

class Tests

  def self.suite
    suite = Test::Unit::TestSuite.new
    suite << MySuite.new(MyTestCase)
    suite << AnotherTestCase.suite
    suite
  end

end

Test::Unit::UI::Console::TestRunner.run(Tests.suite)

Документация Test:: Unit документации дает хорошее объяснение того, как работают пакеты.

Ответ 3

НАКОНЕЦ, тестовое устройство реализовано! Woot! Если вы используете v 2.5.2 или новее, вы можете просто использовать это:

Test::Unit.at_start do
  # initialization stuff here
end

Это будет запускаться один раз, когда вы начнете тестирование. Существуют также обратные вызовы, которые запускаются в начале каждого тестового примера (запуск), в дополнение к тем, которые выполняются перед каждым тестом (настройка).

http://test-unit.rubyforge.org/test-unit/en/Test/Unit.html#at_start-class_method

Ответ 4

Хорошо, я сделал в основном то же самое в действительно уродливой и ужасной манере, но это было быстрее.:) Как только я понял, что тесты выполняются в алфавитном порядке:

class MyTests < Test::Unit::TestCase
def test_AASetup # I have a few tests that start with "A", but I doubt any will start with "Aardvark" or "Aargh!"
    #Run setup code
end

def MoreTests
end

def test_ZTeardown
    #Run teardown code
end

Это неплохо, но он работает:)

Ответ 5

Чтобы решить эту проблему, я использовал конструкцию установки, в которой использовался только один метод тестирования. Этот один тестовый метод вызывает все другие тесты.

Например

class TC_001 << Test::Unit::TestCase
  def setup
    # do stuff once
  end

  def testSuite
    falseArguments()
    arguments()
  end

  def falseArguments
    # do stuff
  end

  def arguments
    # do stuff
  end
end

Ответ 6

Я знаю, что это довольно старая статья, но у меня была проблема (и я уже писал классы с использованием Tes/unit), а ave ответил с помощью другого метода, поэтому, если это может помочь...

Если вам нужен только эквивалент функции запуска, вы можете использовать переменные класса:

class MyTest < Test::Unit::TestCase
  @@cmptr = nil
  def setup
    if @@cmptr.nil?
      @@cmptr = 0
      puts "runs at first test only"
      @@var_shared_between_fcs = "value"
    end
    puts 'runs before each test'
  end
  def test_stuff
    assert(true)
  end
end

Ответ 7

Я столкнулся с этой точной проблемой и создал подкласс Test::Unit::TestCase для выполнения именно того, что вы описали.

Вот что я придумал. Он предоставляет собственные методы setup и teardown, которые подсчитывают количество методов в классе, которые начинаются с 'test'. При первом вызове setup он вызывает global_setup и при последнем вызове teardown он вызывает global_teardown

class ImprovedUnitTestCase < Test::Unit::TestCase
  cattr_accessor :expected_test_count

  def self.global_setup; end
  def self.global_teardown; end    

  def teardown
    if((self.class.expected_test_count-=1) == 0)
      self.class.global_teardown
    end
  end
  def setup
    cls = self.class

    if(not cls.expected_test_count)
      cls.expected_test_count = (cls.instance_methods.reject{|method| method[0..3] != 'test'}).length
      cls.global_setup
    end
  end
end

Создайте свои тестовые примеры следующим образом:

class TestSomething < ImprovedUnitTestCase
  def self.global_setup
    puts 'global_setup is only run once at the beginning'
  end

  def self.global_teardown
    puts 'global_teardown is only run once at the end'
  end

  def test_1 
  end

  def test_2
  end
end

Ошибка в этом состоит в том, что вы не можете предоставить свои собственные методы для каждого теста setup и teardown, если вы не используете метод класса setup :method_name (доступен только в Rails 2.X?), и если у вас есть набор тестов или что-то, что только запускает один из методов тестирования, тогда global_teardown не будет вызываться, потому что он предполагает, что все тестовые методы будут запущены в конечном итоге.

Ответ 8

Используйте TestSuite как @romulo-a-ceccon, описанный для специальных приготовлений для каждого набора тестов.

Однако я думаю, что здесь следует упомянуть, что тесты Unit предназначены для полной изоляции. Таким образом, поток выполнения - это установка-тестирование-отключение, которое должно гарантировать, что каждый тестовый прогон невозможен ничем иным, чем другие тесты.

Ответ 9

Я создал mixin с именем SetupOnce. Вот пример его использования.

require 'test/unit'
require 'setuponce'


class MyTest < Test::Unit::TestCase
  include SetupOnce

  def self.setup_once
    puts "doing one-time setup"
  end

  def self.teardown_once
    puts "doing one-time teardown"
  end

end

И вот реальный код; Обратите внимание, что для этого требуется другой модуль, доступный из первой ссылки в сносках.

require 'mixin_class_methods' # see footnote 1

module SetupOnce
  mixin_class_methods

  define_class_methods do
    def setup_once; end

    def teardown_once; end

    def suite
      mySuite = super

      def mySuite.run(*args)
        @name.to_class.setup_once
        super(*args)
        @name.to_class.teardown_once
      end

      return mySuite
    end
  end
end

# See footnote 2
class String
  def to_class
    split('::').inject(Kernel) {
      |scope, const_name|
      scope.const_get(const_name)
    }
  end
end

Сноска:

• http://redcorundum.blogspot.com/2006/06/mixing-in-class-methods.html

• http://infovore.org/archives/2006/08/02/getting-a-class-object-in-ruby-from-a-string-containing-that-classes-name/

Ответ 10

+1 для ответа RSpec выше на @orion-edwards. Я бы прокомментировал его ответ, но у меня пока нет достаточной репутации, чтобы комментировать ответы.

Я использую test/unit и RSpec много, и я должен сказать... в коде, который каждый опубликовал, отсутствует очень важная функция before(:all), которая: поддержка переменной @instance.

В RSpec вы можете:

describe 'Whatever' do
  before :all do
    @foo = 'foo'
  end

  # This will pass
  it 'first' do
    assert_equal 'foo', @foo
    @foo = 'different'
    assert_equal 'different', @foo
  end

  # This will pass, even though the previous test changed the 
  # value of @foo.  This is because RSpec stores the values of 
  # all instance variables created by before(:all) and copies 
  # them into your test scope before each test runs.
  it 'second' do
    assert_equal 'foo', @foo
    @foo = 'different'
    assert_equal 'different', @foo
  end
end

Реализации #startup и #shutdown прежде всего направлены на то, чтобы эти методы вызывались только один раз для всего класса TestCase, но любые переменные экземпляра, используемые в этих методах, будут потеряны!

RSpec запускает свой before(:all) в своем собственном экземпляре Object и все локальные переменные копируются до запуска каждого теста.

Чтобы получить доступ ко всем переменным, созданным во время глобального метода #startup, вам необходимо либо:

• скопируйте все переменные экземпляра, созданные #startup, например RSpec
• определите ваши переменные в #startup в области, доступ к которой вы можете получить из своих методов тестирования, например. @@class_variables или создать attr_accessors на уровне класса, обеспечивающие доступ к @instance_variables, который вы создаете внутри def self.startup

Просто мои $0,02!