มีปัญหาในการเปรียบเทียบเวลากับ RSpec

ฉันใช้ Ruby บน Rails 4 และ rspec-rail gem 2.14 สำหรับอ็อบเจ็กต์ของฉันฉันต้องการเปรียบเทียบเวลาปัจจุบันกับupdated_atแอ็ตทริบิวต์อ็อบเจ็กต์หลังจากรันแอ็คชันคอนโทรลเลอร์ แต่ฉันมีปัญหาเนื่องจากข้อมูลจำเพาะไม่ผ่าน นั่นคือกำหนดต่อไปนี้เป็นรหัสข้อมูลจำเพาะ:

it "updates updated_at attribute" do
  Timecop.freeze

  patch :update
  @article.reload
  expect(@article.updated_at).to eq(Time.now)
end

เมื่อฉันเรียกใช้ข้อมูลจำเพาะข้างต้นฉันได้รับข้อผิดพลาดต่อไปนี้:

Failure/Error: expect(@article.updated_at).to eq(Time.now)

   expected: 2013-12-05 14:42:20 UTC
        got: Thu, 05 Dec 2013 08:42:20 CST -06:00

   (compared using ==)

ฉันจะทำ spec ให้ผ่านได้อย่างไร?

หมายเหตุ : ฉันลองทำสิ่งต่อไปนี้แล้วด้วย (สังเกตการutcเพิ่มเติม):

it "updates updated_at attribute" do
  Timecop.freeze

  patch :update
  @article.reload
  expect(@article.updated_at.utc).to eq(Time.now)
end

แต่ข้อมูลจำเพาะยังไม่ผ่าน (สังเกตความแตกต่างของค่า "got"):

Failure/Error: expect(@article.updated_at.utc).to eq(Time.now)

   expected: 2013-12-05 14:42:20 UTC
        got: 2013-12-05 14:42:20 UTC

   (compared using ==)

วัตถุ Ruby Time รักษาความแม่นยำมากกว่าฐานข้อมูล เมื่ออ่านค่ากลับจากฐานข้อมูลค่าจะถูกเก็บไว้เป็นความแม่นยำระดับไมโครวินาทีเท่านั้นในขณะที่การแสดงค่าในหน่วยความจำนั้นแม่นยำถึงนาโนวินาที

หากคุณไม่สนใจความแตกต่างเพียงมิลลิวินาทีคุณสามารถทำ to_s / to_i ได้ทั้งสองด้านของความคาดหวังของคุณ

expect(@article.updated_at.utc.to_s).to eq(Time.now.to_s)

หรือ

expect(@article.updated_at.utc.to_i).to eq(Time.now.to_i)

อ้างถึงนี้สำหรับข้อมูลเพิ่มเติมเกี่ยวกับสาเหตุที่เวลาจะแตกต่างกัน

ฉันพบว่าการใช้ตัวbe_withinจับคู่ rspec เริ่มต้นนั้นหรูหรากว่า:

expect(@article.updated_at.utc).to be_within(1.second).of Time.now

โพสต์เก่า แต่ฉันหวังว่ามันจะช่วยทุกคนที่เข้ามาที่นี่เพื่อหาแนวทางแก้ไข ฉันคิดว่าการสร้างวันที่ด้วยตนเองนั้นง่ายและน่าเชื่อถือกว่า:

it "updates updated_at attribute" do
  freezed_time = Time.utc(2015, 1, 1, 12, 0, 0) #Put here any time you want
  Timecop.freeze(freezed_time) do
    patch :update
    @article.reload
    expect(@article.updated_at).to eq(freezed_time)
  end
end

เพื่อให้แน่ใจว่าวันที่จัดเก็บเป็นวันที่ถูกต้องโดยไม่ต้องทำto_xหรือกังวลเรื่องทศนิยม

ใช่ตามที่Oinแนะนำให้be_withinจับคู่เป็นแนวทางปฏิบัติที่ดีที่สุด

... และมี uscases เพิ่มเติม -> http://www.eq8.eu/blogs/27-rspec-be_within-matcher

แต่อีกวิธีหนึ่งในการจัดการกับปัญหานี้คือการใช้ Rails ในตัวmiddayและmiddnightแอตทริบิวต์

it do
  # ...
  stubtime = Time.now.midday
  expect(Time).to receive(:now).and_return(stubtime)

  patch :update 
  expect(@article.reload.updated_at).to eq(stubtime)
  # ...
end

ตอนนี้เป็นเพียงการสาธิตเท่านั้น!

ฉันจะไม่ใช้สิ่งนี้ในคอนโทรลเลอร์เนื่องจากคุณกำลังหยุดทำงานตลอดเวลาการโทรใหม่ => แอตทริบิวต์เวลาทั้งหมดจะมีเวลาเท่ากัน => อาจไม่สามารถพิสูจน์แนวคิดที่คุณพยายามบรรลุได้ ฉันมักจะใช้ใน Ruby Objects ที่ประกอบด้วยสิ่งนี้:

class MyService
  attr_reader :time_evaluator, resource

  def initialize(resource:, time_evaluator: ->{Time.now})
    @time_evaluator = time_evaluator
    @resource = resource
  end

  def call
    # do some complex logic
    resource.published_at = time_evaluator.call
  end
end

require 'rspec'
require 'active_support/time'
require 'ostruct'

RSpec.describe MyService do
  let(:service) { described_class.new(resource: resource, time_evaluator: -> { Time.now.midday } ) }
  let(:resource) { OpenStruct.new }

  it do
    service.call
    expect(resource.published_at).to eq(Time.now.midday)    
  end
end

แต่จริงๆแล้วฉันขอแนะนำให้ใช้be_withinตัวจับคู่แม้ว่าจะเปรียบเทียบ Time.now.midday!

ใช่แล้วกรุณาติดกับbe_withinmatcher;)

อัปเดต 2017-02

คำถามในความคิดเห็น:

จะเกิดอะไรขึ้นถ้าเวลาอยู่ใน Hash? วิธีใดที่จะทำให้คาดหวัง (hash_1) .to eq (hash_2) ทำงานได้เมื่อค่า hash_1 บางค่าเป็นค่าก่อน db-times และค่าที่เกี่ยวข้องใน hash_2 เป็น post-db-times? -

expect({mytime: Time.now}).to match({mytime: be_within(3.seconds).of(Time.now)}) `

คุณสามารถส่งตัวจับคู่ RSpec ไปยังตัวmatchจับคู่ได้ (เช่นคุณสามารถทำการทดสอบ API ด้วย RSpec บริสุทธิ์ได้ )

สำหรับ "post-db-times" ฉันเดาว่าคุณหมายถึงสตริงที่สร้างขึ้นหลังจากบันทึกลงใน DB ฉันขอแนะนำให้แยกกรณีนี้ออกเป็น 2 ความคาดหวัง (หนึ่งในการตรวจสอบโครงสร้างแฮชครั้งที่สองตรวจสอบเวลา) ดังนั้นคุณสามารถทำสิ่งต่างๆเช่น:

hash = {mytime: Time.now.to_s(:db)}
expect(hash).to match({mytime: be_kind_of(String))
expect(Time.parse(hash.fetch(:mytime))).to be_within(3.seconds).of(Time.now)

แต่ถ้ากรณีนี้บ่อยเกินไปในชุดทดสอบของคุณฉันขอแนะนำให้เขียนRSpec matcherของคุณเอง (เช่นbe_near_time_now_db_string) การแปลงเวลาสตริง db เป็น Time object จากนั้นใช้สิ่งนี้เป็นส่วนหนึ่งของmatch(hash):

 expect(hash).to match({mytime: be_near_time_now_db_string})  # you need to write your own matcher for this to work.

คุณสามารถแปลง datetime / / to_s(:db)วัตถุวันเวลาที่จะสตริงที่มันเก็บไว้ในฐานข้อมูลด้วย

expect(@article.updated_at.to_s(:db)).to eq '2015-01-01 00:00:00'
expect(@article.updated_at.to_s(:db)).to eq Time.current.to_s(:db)

วิธีที่ง่ายที่สุดที่ฉันพบในปัญหานี้คือสร้างวิธีcurrent_timeการทดสอบผู้ช่วยดังนี้:

module SpecHelpers
  # Database time rounds to the nearest millisecond, so for comparison its
  # easiest to use this method instead
  def current_time
    Time.zone.now.change(usec: 0)
  end
end

RSpec.configure do |config|
  config.include SpecHelpers
end

ตอนนี้เวลาจะปัดเศษเป็นมิลลิวินาทีที่ใกล้ที่สุดเสมอเพื่อการเปรียบเทียบจะตรงไปตรงมา:

it "updates updated_at attribute" do
  Timecop.freeze(current_time)

  patch :update
  @article.reload
  expect(@article.updated_at).to eq(current_time)
end

เนื่องจากฉันกำลังเปรียบเทียบแฮชวิธีแก้ปัญหาเหล่านี้ส่วนใหญ่ไม่ได้ผลสำหรับฉันดังนั้นฉันจึงพบวิธีที่ง่ายที่สุดคือเพียงแค่ดึงข้อมูลจากแฮชที่ฉันกำลังเปรียบเทียบ เนื่องจากเวลา updated_at ไม่เป็นประโยชน์สำหรับฉันในการทดสอบการทำงานนี้ได้ผล

data = { updated_at: Date.new(2019, 1, 1,), some_other_keys: ...}

expect(data).to eq(
  {updated_at: data[:updated_at], some_other_keys: ...}
)