테스트 할 때 테스트 대기열과 실제 대기열을 구분하는 방법은 무엇입니까? (rspec 및 레일을 사용하여) Resque를 테스트 할 때

Question

일부 resque 작업자와 이러한 작업자와 작업을 대기열에 추가하는 작업을 테스트하고 싶습니다. 나는 rspec과 레일을 사용하고있다.

현재 모델이 있습니다. Categories.port와 함께 작업을 대기열에 추가해야 하는지를 확인하는 updates_related_categories라는 before_save 메소드가있는 Article.rb를 모델이라고합니다. 그렇다면 기사는 해당 기사와 관련된 카테고리 ID의 인수를 사용하여 해당 작업자와 함께 작업을 대기열에 추가합니다.

그러나 테스트에서 이러한 작업은 개발 서버가 작업을 보내는 큐와 동일한 큐로 보내집니다.

이

1) 어떻게 개발 작업과는 다른 큐에 테스트 작업을 보낼 수 있습니다 내가 알고 싶은

(난 당신이 루트/레디 스/개요에서 서버로 묶을 수있는 resque 서버를 사용하여 확인) ?

가능하다면, resque 테스트에 대한 다른 조언도 환영합니다.

resque-unit 및 resque-spec을 제안하는 몇 가지 관련 질문을 보았습니다. 그러나 이들은 아직 개발되지 않았기 때문에 유용한 작업 상태로 만들 수 없습니다. 또한 Resque.inline을 사용하는 것에 대해 들어 봤지만이 경우에는 관련이 있는지 모릅니다. 테스트 사양에서 resque가 호출되지 않았으므로 테스트에서 생성 된 개체를 저장할 때 문서 모델에서 호출되었습니다.

샘플 코드 :

Article.rb :

before_save :update_related_categories 
def update_related_categories 
    #some if statements/checks to see if a related category needs updating 
     Resque.enqueue(CategoriesWorker, [category_id]) 
    end 
end 

CategoriesSorter :

class CategoriesSorter 
    @queue=:sorting_queue 
    def self.perform(ids) 
     ids.each do |id| 
      #some code 
     end 
     end 
end 

사양 :

it "should do something" do 
    @article = #set something to enqueue a job 
    @article.save 
    #can i check if a job is enqueued? can i send this job NOT to the development queue but a different one? 
end 

Answer 1

제가보기에, 작업을 대기열에 추가하면 호출이 수행되는 결과가 나오는지 테스트하지 않으려합니다. . 그러나이를 테스트 할 수 있습니다. 1. update_related_categories를 호출하면 작업이 대기열에 포함됩니다. 그런 다음 작업 수행 호출자가 원하는 동작을 수행하는지 여부를 별도로 테스트 할 수 있습니다.

일반적으로 Resque 테스트의 경우 resque-spec과 작업자 시뮬레이션을 조합하면 위의 두 가지 목표를 달성 할 수 있습니다.경우 1

, resque 스펙과 함께, 당신은 작업자가이 클래스에 방법을 수행 호출 시뮬레이션하고 올바르게 큐에 넣어 된 것을 확인할 수 있습니다

describe "Calling update_related_categories " do 
    before(:each) do 
    ResqueSpec.reset! 
    end 

    it "should enqueue the job" do 
    Article.update_related_categories 
    CategoriesSorter.should have_queue_size_of(1) 
    end 
end 

2를 들어, 작업을 만들 수 있습니다 당신에게 몇 가지 아이디어를 제공

def run_worker_simulation 
    # see Resque::Job api for setting the args you want 
    Resque::Job.create('test_queue_name', 'class_name', 'type', 'id') 

    worker = Resque::Worker.new('test_queue_name') 
    worker.very_verbose = true 

    job = worker.reserve 
    worker.perform(job) 
end 

희망 : 작업에 근로자를 할당 다음, Resque :: 작업자 (및 개발 큐보다 별도의 큐의 이름을 지정)합니다.

Answer 2

당신은 resque을 테스트 안가, 그게 resque입니다 개발 팀 일, 응용 프로그램은 perfom 메서드가 수행해야하는 작업 만 수행하는지 테스트해야합니다. 또한 모델 Article.rb가 원하는대로 작업을 대기열에 포함하는지 테스트 할 수 있습니다. 진짜 일을 보내는 것은 쓸모가 없다. 시험은 끝나고 대기열은 쓸데없는 일로 가득 차게 될 것이다.

수행과 같은 :

describe 'Article' do 
    before(:each) do 
    Resque.stub!(:enqueue) 
    end 

    it 'enqueues the job' do 
    cat_id = 1 
    Resque.should_receive(:enqueue).once.with(CategoriesWorker, [cat_id]) 
    Article.create(:category_id => cat_id) 
    end 
end 

describe 'CategoriesSorter' do 
    it 'sorts the categories' do 
    result = CategoriesSorter.perform([1,4,6,3,2]) 
    result.should == [1,2,3,4,6] 
    end 
end 

스텁 또는 모의 불필요한 방법/클래스

편집 : (각) resque를 스텁 필터링이 기사 테스트로도, 그것은 당신이 전에이 설정하는 것이 좋다 그래서 당신의 스펙은 결코 실제 대기열로 작업을 보내지 않습니다. 내 대답을 편집했습니다.

Answer 3

나는이 테스트 환경에서 인라인으로 모든 resque 작업을하게

Resque.inline = ENV['RAILS_ENV'] == "test" 

있습니다.

각각의 작업 클래스를 테스트하기 위해 테스트 할 별도의 사양이 개의 메서드 각각을 수행해야합니다.