Problemas para comparar o tempo com RSpec

Estou usando Ruby on Rails 4 e rspec-rails gem 2.14. Para um meu objeto, gostaria de comparar a hora atual com o updated_atatributo do objeto após a execução de uma ação do controlador, mas estou com problemas porque a especificação não passa. Ou seja, dado o seguinte está o código de especificação:

it "updates updated_at attribute" do
  Timecop.freeze

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

Quando executo a especificação acima, recebo o seguinte erro:

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

Como posso fazer a especificação passar?

Observação : tentei também o seguinte (observe a utcadição):

it "updates updated_at attribute" do
  Timecop.freeze

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

mas a especificação ainda não passa (observe a diferença de valor "obtido"):

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

O objeto Ruby Time mantém uma precisão maior do que o banco de dados. Quando o valor é lido de volta no banco de dados, ele é preservado apenas na precisão de microssegundos, enquanto a representação na memória é precisa em nanossegundos.

Se você não se importa com a diferença de milissegundos, você poderia fazer um to_s / to_i em ambos os lados da sua expectativa

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

ou

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

Consulte isso para obter mais informações sobre por que os horários são diferentes

Acho que usar o be_withinmatcher rspec padrão é mais elegante:

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

Sim, pois Oinestá sugerindo que o be_withinmatcher é a melhor prática

... e tem mais alguns uscases -> http://www.eq8.eu/blogs/27-rspec-be_within-matcher

Mas mais uma maneira de lidar com isso é usar atributos middaye embutidos do Rails 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

Agora, isso é apenas para demonstração!

Eu não usaria isso em um controlador, pois você está copiando todas as chamadas Time.new => todos os atributos de tempo terão o mesmo tempo => pode não provar o conceito que você está tentando alcançar. Eu geralmente o uso em objetos Ruby compostos semelhantes a este:

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

Mas, honestamente, eu recomendo ficar com o be_withinmatcher, mesmo quando estiver comparando Time.now.midday!

Então, sim, por be_withinfavor, use o combinador;)

atualização 2017-02

Pergunta no comentário:

e se os tempos estiverem em um Hash? alguma maneira de fazer expect (hash_1) .to eq (hash_2) funcionar quando alguns valores hash_1 são pré-tempos db e os valores correspondentes em hash_2 são tempos pós-db? -

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

você pode passar qualquer matcher RSpec para o matchmatcher (então, por exemplo, você pode até mesmo fazer testes de API com RSpec puro )

Quanto a "tempos pós-db", acho que você quer dizer string que é gerada após salvar no banco de dados. Eu sugeriria desacoplar este caso de 2 expectativas (uma garantindo a estrutura hash, a segunda verificando o tempo) para que você possa fazer algo como:

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)

Mas se este caso for muito frequente em seu conjunto de testes, eu sugeriria escrever seu próprio matcher RSpec (por exemplo be_near_time_now_db_string) convertendo o tempo da string db para o objeto Time e então usar isso como parte de match(hash):

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

Postagem antiga, mas espero que ajude quem entrar aqui por uma solução. Acho que é mais fácil e confiável apenas criar a 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

Isso garante que a data armazenada seja a correta, sem fazer to_xou se preocupar com decimais.

Você pode converter o objeto de data / data / hora / hora em uma string conforme é armazenado no banco de dados com 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)

A maneira mais fácil que encontrei de contornar esse problema é criar um current_timemétodo auxiliar de teste assim:

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

Agora, o tempo é sempre arredondado para o milissegundo mais próximo para que as comparações sejam diretas:

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

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

Como eu estava comparando hashes, a maioria dessas soluções não funcionou para mim, então descobri que a solução mais fácil era simplesmente pegar os dados do hash que estava comparando. Uma vez que os updates_at times não são realmente úteis para eu testar, isso funciona bem.

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

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