Probleme beim Zeitvergleich mit RSpec

Ruby-Zeit-Objekt verwaltet eine größere Präzision als die Datenbank hat. Wenn der Wert wieder zu Lesen aus der Datenbank, es wird nur beibehalten, um Mikrosekunden-Genauigkeit, während die in-memory-Darstellung ist präzise bis Nanosekunden.

Wenn Sie kümmern sich nicht um Millisekunden-Unterschied, könnte man einen to_s/to_i auf beiden Seiten Ihrer Erwartung

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

oder

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

Finden diese für weitere Informationen, warum die Zeiten unterschiedlich sind

InformationsquelleAutor der Antwort usha

Alte post, aber ich hoffe, es hilft wer tritt hier für eine Lösung. Ich denke, es ist einfacher und zuverlässiger zu erstellen die das Datum manuell ein:

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)

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

Dies gewährleistet das gespeicherte Datum ist das richtige, ohne dabei to_x oder sich Gedanken über Dezimalzahlen.

InformationsquelleAutor der Antwort jBilbo

yep als Oin suggeriert be_within matcher ist die beste Praxis

...und es hat etwas mehr uscases -> http://www.eq8.eu/blogs/27-rspec-be_within-matcher

Aber noch eine weitere Art und Weise, wie damit umzugehen ist die Verwendung von Schienen gebaut midday und middnight Attribute.

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

Nun, dies ist nur zur demonstration !

Ich würde nicht verwenden Sie diese in einem controller, wie Sie sind stubbing alle Zeit.die neuen Aufrufe => alle Attribute haben gleichen Zeit => kann nicht beweisen Konzept, das Sie versuchen zu erreichen. Normalerweise verwende ich es in der komponierten Ruby-Objekte ähnlich wie diese:

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

Aber ehrlich gesagt, ich empfehlen, kleben mit be_within matcher auch beim Vergleich der Zeit.nun.Mittag !

Also ja pls stick mit be_within matcher 😉

update 2017-02

Frage im Kommentar:

was ist, wenn die Zeiten werden in einem Hash? jeder Weg, zu erwarten(hash_1).zu eq(hash_2) funktionieren, wenn einige hash_1 Werte sind pre-db-Zeiten und die entsprechenden Werte in hash_2 sind post-db-Zeiten? –

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

können Sie weitergeben, RSpec-matcher, um die match matcher
(also z.B. man kann sogar API-Test mit reinem RSpec)

Als für "post-db-mal" - ich denke mal du meinst string, der generiert wird, nachdem speichern in der DB. Ich würde vorschlagen, entkoppeln diesem Fall um 2 Erwartungen (sicherstellen, dass die hash-Struktur, die zweite Prüfung der Zeit) So etwas wie:

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)

Aber wenn dieser Fall auch oft in der test-suite würde ich vorschlagen, schreiben Sie Ihre eigene RSpec-matcher (z.B. be_near_time_now_db_string) Umwandlung von db-string, Zeit, Zeit, Objekt und verwenden Sie dies als Teil des match(hash) :

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

InformationsquelleAutor der Antwort equivalent8