Создание почти идентичных тестов рубинового кода

Question

У меня есть несколько рубиновых файлов (, b.rb, c.rb), которые определяют очень похожие классы. (Они должны проверить то же самое)

Я написал единичный тест для тестирования этих подклассов, и я сгенерировал контексты для каждого из классов программно (см. Ниже) - вместо этого я вместо этого программно создаю целые классы тестов? Если да, то почему и как?

Я использую расширения тестовых shoulda единицы, так что мои файлы выглядеть примерно так:

a.rb

class ItsA 
    def number 
    1123 
    end 
end 

b.rb

class ItsB 
    def number 
    6784 
    end 
end 

test_letters.rb

require 'rubygems' 
require 'test/unit' 
require 'shoulda' 

class LettersTest < Test::Unit::TestCase 
    Dir.glob('letters/*.rb') do |letter| 
    context "The #{letter} letter file" 
     setup do 
     # Here I require the ruby file and allocate 
     # @theclass to be an instance of the class in the file. 
     # I'm actually testing JavaScript using Harmony, but 
     # putting those details in might complicate my question. 
     end 

     should "return a number" do 
     assert @theclass.number.is_a? Number 
     end 
    end 
    end 

Это делает работу достаточно хорошо, но я должен сделать некоторые другие jiggerypokery и создать LetterATest, LetterBTest и т.д. автоматически вместо этого? Если да, как бы вы это сделали и почему?

Answer 1

Это действительно зависит от того, насколько похожи ваши классы, но при условии, что они в значительной степени идентичны и требуют несколько небольших тестов, и вы используете Shoulda, вы могли бы сделать что-то вроде:

class LettersTest < Test::Unit::TestCase 
    context "The letter classes" 
    setup do 
     @instances = # your code to get a list of the instances 
    end 

    should "return a number" do 
     @instances.each do |instance| 
     assert instance.number.is_a?(Number), "#{instance.class}.number should be a number" 
     end 
    end 
    end 
end 

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