Обнаружение перезаписи методов тестирования ruby - PullRequest
3 голосов
/ 20 февраля 2009

Если вы напишите тестовый класс, как

class MyTest < Test::Unit::TestCase 
  def setup 
  end

  def test_1 
    flunk
  end

  def test_1 
    assert true
  end
end

первый тест_1 игнорируется. Хотя это выглядит глупой ошибкой, это может произойти при программировании копирования и вставки. Помимо бега

grep test test_me.rb | wc

и, сравнивая это с тем, сколько тестов тестовый модуль выполнил, или используя rcov или heckle, или работая с -w, как вы можете обнаружить такие проблемы?

Кроме того, есть ли способ указать, что методы тестирования не должны быть перезаписаны?

Редактировать : У тестируемого метода был параметр с 6 или около того возможными значениями, и тестировщик хотел протестировать каждый сценарий. Вот почему было использовано программирование копирования и вставки. Единственная альтернатива, которую я могу предусмотреть для такого сценария, - это набор из шести элементов с параметрами и ожидаемыми значениями.

Ответы [ 6 ]

5 голосов
/ 20 февраля 2009

Вы можете воспользоваться method_added, который вызывается в Ruby при каждом добавлении метода в класс. Вы должны быть в состоянии включить что-то в модуль, который вы включаете, но вот простой пример того, как сделать это внутри вашего тестового класса.

class MyTest < Test::Unit::TestCase

  @@my_tests = []

  def self.method_added(sym)
    raise "#{sym} already defined!" if @@my_tests.include? sym
    @my_tests << sym
  end

  def test_foo_1
  end

  def test_foo_2
  end

  def test_foo_1
  end
end
2 голосов
/ 21 февраля 2009

Что касается ответа HermanD, так как это Ruby !, вы также можете сделать это прямо в классе для создания уникальных методов тестирования:

class MyObjectTest < Test::Unit::TestCase
  [
   {:param => 1, :expected => 'whatever is expected'},
   {:param => 2, :expected => 'whatever is expected'},
   {:param => 3, :expected => 'whatever is expected'},
   {:param => 4, :expected => 'whatever is expected'},
   {:param => 5, :expected => 'whatever is expected'},
   {:param => 6, :expected => 'whatever is expected'}
  ].each do |test_case|
    define_method :"test_using_#{test_case[:param]}_should_return_#{params[:expected].underscore}" do
      assert_equal test_case[:expected], MyObject.new.do_something_with(test_case[:param])
    end
  end
end

Это кажется еще более естественным, если использовать предложение Rspec (или Следует) как язык:

describe MyObject do
   [
   {:param => 1, :expected => 'whatever is expected'},
   {:param => 2, :expected => 'whatever is expected'},
   {:param => 3, :expected => 'whatever is expected'},
   {:param => 4, :expected => 'whatever is expected'},
   {:param => 5, :expected => 'whatever is expected'},
   {:param => 6, :expected => 'whatever is expected'}
  ].each do |test_case|
    it "should return #{test_case[:expected]} when using #{test_case[:param]}" do
      MyObject.new.do_something_with(test_case[:param]).should == test_case[:expected]
    end
  end
end
2 голосов
/ 21 февраля 2009

Редактировать: тестируемый метод имел параметр с 6 или около того возможно значения, и тестер хотел проверить каждый сценарий. Вот почему копировать и было использовано программирование пасты.

В этих обстоятельствах я делаю это:

def test_foo
  test_cases = [
   {:param => 1, :expected => 'whatever is expected'},
   {:param => 2, :expected => 'whatever is expected'},
   {:param => 3, :expected => 'whatever is expected'},
   {:param => 4, :expected => 'whatever is expected'},
   {:param => 5, :expected => 'whatever is expected'},
   {:param => 6, :expected => 'whatever is expected'}
  ]

  for test_case in test_cases
    do_the_test(test_case)
  end
end

def do_the_test(test_case)
  # test code here
end

Это полностью исключает копирование и вставку, что, как уже было сказано, плохо

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

Точно!

1 голос
/ 20 февраля 2009

Действительно ли это проблема, если вы даете своим тестам правильные описательные имена? Вот пример некоторых имен методов тестирования из моего последнего проекта:

test_should_not_do_html_escaping_for_administrators
test_should_not_be_able_to_create_project_with_company_user_doesnt_own
test_should_be_able_to_edit_own_projects
test_should_not_be_able_to_edit_others_projects

Если имена ваших тестов достаточно короткие, чтобы их можно было легко перезаписать или дублировать, возможно, вы недостаточно описательны в отношении того, что вы на самом деле тестируете в каждом из них.

0 голосов
/ 10 марта 2010

Gem-версия test-unit имеет возможность определять переопределение теста с 2.0.7 .

0 голосов
/ 20 февраля 2009

Избегайте копирования-вставки программирования. При необходимости повторно свяжите сочетания клавиш.

...