Problemi nel confrontare il tempo con RSpec

Sto usando Ruby su Rails 4 e rspec-rails gem 2.14. Per un oggetto my vorrei confrontare l'ora corrente con l' updated_atattributo object dopo l'esecuzione di un'azione del controller, ma sono nei guai poiché la specifica non viene superata. Cioè, dato quanto segue è il codice delle specifiche:

it "updates updated_at attribute" do
  Timecop.freeze

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

Quando eseguo la specifica sopra, ottengo il seguente errore:

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 ==)

Come posso far passare la specifica?

Nota : ho provato anche quanto segue (nota il fileutc aggiunta):

it "updates updated_at attribute" do
  Timecop.freeze

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

ma la specifica continua a non essere soddisfatta (nota la differenza di valore "ottenuto"):

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 ==)

L'oggetto Ruby Time mantiene una precisione maggiore rispetto al database. Quando il valore viene riletto dal database, viene conservato solo con una precisione al microsecondo, mentre la rappresentazione in memoria è precisa al nanosecondo.

Se non ti interessa la differenza di millisecondi, potresti fare un to_s / to_i su entrambi i lati delle tue aspettative

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

o

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

Fare riferimento a questo per ulteriori informazioni sul motivo per cui i tempi sono diversi

Trovo be_withinpiù elegante l'utilizzo del matcher rspec predefinito:

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

sì, come Oinsuggerisce che il be_withinmatcher sia la migliore pratica

... e ha altre uscases -> http://www.eq8.eu/blogs/27-rspec-be_within-matcher

Ma un altro modo per affrontare questo problema è usare Rails integrato middaye middnightattributi.

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

Ora questo è solo per dimostrazione!

Non lo userei in un controller perché stai bloccando tutte le chiamate Time.new => tutti gli attributi temporali avranno lo stesso tempo => potrebbe non dimostrare il concetto che stai cercando di ottenere. Di solito lo uso in oggetti Ruby composti simili a questo:

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

Ma onestamente consiglio di restare con be_withinMatcher anche quando confronti Time.now.midday!

Quindi sì, ti prego di attaccare con be_withinmatcher;)

aggiornamento 2017-02

Domanda nel commento:

cosa succede se i tempi sono in un hash? qualche modo per far funzionare l'aspettativa (hash_1) .to eq (hash_2) quando alcuni valori hash_1 sono pre-db-time ei valori corrispondenti in hash_2 sono post-db-time? -

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

puoi passare qualsiasi matcher RSpec al matchmatcher (così ad esempio puoi anche eseguire test API con RSpec puro )

Per quanto riguarda "post-db-times", immagino che tu intenda una stringa generata dopo il salvataggio su DB. Suggerirei di disaccoppiare questo caso a 2 aspettative (una che garantisce la struttura hash, la seconda controlla l'ora) Quindi puoi fare qualcosa come:

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)

Ma se questo caso è troppo spesso nella tua suite di test, suggerirei di scrivere il tuo RSpec matcher (ad esempio be_near_time_now_db_string) convertendo il tempo della stringa db in oggetto Time e quindi usalo come parte di match(hash):

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

Vecchio post, ma spero che aiuti chiunque entri qui per una soluzione. Penso che sia più facile e più affidabile creare la data manualmente:

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

Ciò garantisce che la data memorizzata sia quella giusta, senza fare to_xo preoccuparsi dei decimali.

È possibile convertire l'oggetto data / datetime / ora in una stringa poiché è archiviato nel database con 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)

Il modo più semplice che ho trovato per aggirare questo problema è creare un current_timemetodo helper di test in questo modo:

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

Ora il tempo è sempre arrotondato al millisecondo più vicino ai confronti sono semplici:

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

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

Poiché stavo confrontando gli hash, la maggior parte di queste soluzioni non funzionava per me, quindi ho scoperto che la soluzione più semplice era semplicemente prendere i dati dall'hash che stavo confrontando. Poiché i tempi updated_at non sono effettivamente utili per me per testare questo funziona bene.

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

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