2009-11-15 3 views
3

기본적으로 마지막 x (변수는 있지만 여기에 x가 20이라고 가정합니다) 업데이트가 주어진 테이블에서 만들어진 코드가 있습니다. 그것을위한 단위 테스트 중 하나에서,이 조각이 :created_at by 단위 테스트에서 생성 된 데이터를 레일로 배열

EditedItem.push_to_queue(hiddennow) 
#create some new entries and save them 
20.times{ EditedItem.push_to_queue(random_item) } 
Queue.get_entries.each{|entry| assert_not_equal too_far_down, entry} 

월 또는 꽤되지 않을 수도 있습니다,하지만 그것을 통해 의도를 가져옵니다. get_entries가 호출 될 때 hiddennow 객체가 너무 멀리 큐에 푸시되었습니다. 더 이상 반환되지 않아야합니다.

#this works 
SearchObject.find(:all, :order => "id desc") 

#this does not, unless the 20.times loop has sleep(1) or something 
SearchObject.find(:all, :order => "created_at desc") 

이 약간 아래로 단순화되어 있지만 20.times 루프는 충분히 빨리 created_at에 order by 절이 구별 할 수없는 일을 추가하는 것 같습니다. 제 질문은 근본적으로 잘못된 것을하고 있습니까? 그렇지 않다면,이 선을 따라 테스트를 작성하는 더 좋은 방법은 무엇입니까? (레일 특히 그 시간) 파일 및 기록에 관련된

답변

5

DigitalRoss가 맞습니다. created_at에는 1 초 단위가 있습니다.

old = EditItem.new(:created_at => 1.second.ago) 
older = EditItem.new(:created_at => 2.seconds.ago) 

또 다른 옵션은 실제로 Time 클래스와 혼란에 스텁 사용하는 것입니다

하나의 옵션은 개체를 만들 때 created_at을 설정하는 것입니다. 다음은 Rspec에서 작동하지만 Mocha와 같은 다른 조롱 프레임 워크로 쉽게 수행 할 수 있습니다.

@seconds = Time.now.to_i 
Time.stub!(:now).and_return{Time.at(@seconds += 5) } 

이것은 당신이 Time.now를 호출 할 때마다 이전 5 초 이상 더 시간을 반환합니다.

당신이하고있는 일이 더 명확하고 의도하지 않은 결과를 초래할 가능성이 적기 때문에 첫 번째 접근 방식을 사용하면 좋습니다.

+0

이것은 내가 생각하기에 Rails를 사용하여 배우고 다루는 까다로운 일입니다. – MBHNYC

1

시간은 통상적으로이 포맷은 연산 형으로 1970 년 이후 초를 유지 Unix time, or POSIX time유지된다.

따라서 이러한 시간은 1 초 단위입니다.

레일은 hiddennow을 주문할 수 없으며 그 사이에 1 초 이상 지연이없는 임의의 항목을 주문할 수 있으며 20 세트는 전혀 주문되지 않습니다.

관련 문제