Problemas para comparar el tiempo con RSpec

Estoy usando Ruby on Rails 4 y la gema rspec-rails 2.14. Para mi objeto, me gustaría comparar la hora actual con el updated_atatributo del objeto después de ejecutar una acción del controlador, pero estoy en problemas porque la especificación no pasa. Es decir, dado lo siguiente es el código de especificación:

it "updates updated_at attribute" do
  Timecop.freeze

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

Cuando ejecuto la especificación anterior, obtengo el siguiente error:

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

¿Cómo puedo aprobar la especificación?

Nota : probé también lo siguiente (tenga en cuenta la utcadición):

it "updates updated_at attribute" do
  Timecop.freeze

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

pero la especificación aún no pasa (tenga en cuenta la diferencia de valor "obtenido"):

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

El objeto Ruby Time mantiene una mayor precisión que la base de datos. Cuando se vuelve a leer el valor de la base de datos, solo se conserva con una precisión de microsegundos, mientras que la representación en memoria es precisa en nanosegundos.

Si no le importa la diferencia de milisegundos, puede hacer un to_s / to_i en ambos lados de su expectativa

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)

Consulte esto para obtener más información sobre por qué los tiempos son diferentes.

Encuentro usar el be_withinmatcher rspec predeterminado más elegante:

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

sí, como Oinsugiere que el be_withinmatcher es la mejor práctica

... y tiene algunos uscases más -> http://www.eq8.eu/blogs/27-rspec-be_within-matcher

Pero una forma más de cómo lidiar con esto es usar Rails integrados middayy middnightatributos.

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

¡Esto es solo para demostración!

No usaría esto en un controlador, ya que está eliminando todas las llamadas de Time.new => todos los atributos de tiempo tendrán el mismo tiempo => puede que no pruebe el concepto que está tratando de lograr. Normalmente lo uso en objetos de Ruby compuestos similares 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

Pero honestamente, recomiendo seguir con el be_withinmatcher incluso al comparar Time.now.midday!

Así que sí, quédate con el be_withinmatcher;)

actualización 2017-02

Pregunta en comentario:

¿y si los tiempos están en un hash? ¿Alguna forma de hacer que wait (hash_1) .to eq (hash_2) funcione cuando algunos valores hash_1 son pre-db-times y los valores correspondientes en hash_2 son post-db-times? -

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

puede pasar cualquier comparador RSpec al matchcomparador (por ejemplo, puede incluso hacer pruebas de API con RSpec puro )

En cuanto a "post-db-times", supongo que te refieres a una cadena que se genera después de guardar en DB. Sugeriría desacoplar este caso a 2 expectativas (una asegurando la estructura hash, la segunda verificando el tiempo) Para que pueda hacer 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)

Pero si este caso se encuentra con demasiada frecuencia en su conjunto de pruebas, le sugiero que escriba su propio comparador RSpec (por ejemplo be_near_time_now_db_string) convirtiendo el tiempo de cadena db en un objeto Time y luego use esto 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.

Publicación antigua, pero espero que ayude a cualquiera que entre aquí en busca de una solución. Creo que es más fácil y confiable crear la fecha 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

Esto asegura que la fecha almacenada sea la correcta, sin tener que to_xpreocuparse por los decimales.

Puede convertir el objeto date / datetime / time en una cadena tal como está almacenado en la base de datos 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)

La forma más fácil que encontré para solucionar este problema es crear un current_timemétodo auxiliar de prueba como este:

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

Ahora, el tiempo siempre se redondea al milisegundo más cercano para que las comparaciones sean sencillas:

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

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

Debido a que estaba comparando hashes, la mayoría de estas soluciones no me funcionaron, así que encontré que la solución más fácil era simplemente tomar los datos del hash que estaba comparando. Dado que updated_at veces no son realmente útiles para mí para probar, esto funciona bien.

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

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