Rails Time inconsistencies with rspec

I'm working with Time in Rails and using the following code to set up the start date and end date of a project:

start_date ||= Time.now
end_date = start_date + goal_months.months

I then clone the object and I'm writing rspec tests to confirm that the attributes match in the copy. The end dates match:

original[end_date]:  2011-08-24 18:24:53 UTC
clone[end_date]:     2011-08-24 18:24:53 UTC

but the spec gives me an error on the start dates:

expected: Wed Aug 24 18:24:53 UTC 2011,
     got: Wed, 24 Aug 2011 18:24:53 UTC +00:00 (using ==)

It's clear the dates are the same, just formatted differently. How is it that they end up getting stored differently in the database, and how do I get them to match? I've tried it with DateTime as well with the same results.

Correction: 开发者_Python百科The end dates don't match either. They print out the same, but rspec errors out on them as well. When I print out the start date and end date, the values come out in different formats:

start date: 2010-08-24T19:00:24+00:00
end date: 2011-08-24 19:00:24 UTC

This usually happens because rspec tries to match different objects: Time and DateTime, for instance. Also, comparable times can differ a bit, for a few milliseconds.

In the second case, the correct way is to use stubbing and mock. Also see TimeCop gem

In the first case, possible solution can be to compare timestamps:

actual_time.to_i.should == expected_time.to_i

I use simple matcher for such cases:

# ./spec/spec_helper.rb
#
# Dir[File.dirname(__FILE__) + "/support/**/*.rb"].each {|f| require f}
#
#
# Usage:
#
# its(:updated_at) { should be_the_same_time_as updated_at }
#
#
# Will pass or fail with message like:
#
# Failure/Error: its(:updated_at) { should be_the_same_time_as 2.days.ago }
# expected Tue, 07 Jun 2011 16:14:09 +0300 to be the same time as Mon, 06 Jun 2011 13:14:09 UTC +00:00


RSpec::Matchers.define :be_the_same_time_as do |expected|
  match do |actual|
    expected.to_i == actual.to_i
  end
end

You should mock the now method of Time to make sure it always match the date in the spec. You never know when a delay will make the spec fail because of some milliseconds. This approach will also make sure that the time on the real code and on the spec are the same.

If you're using the default rspec mock lib, try to do something like:

t = Time.parse("01/01/2010 10:00")
Time.should_receive(:now).and_return(t)

I totally agree with the previous answers about stubbing Time.now. That said there is one other thing going on here. When you compare datetimes from a database you lose some of the factional time that can be in a ruby DateTime obj. The best way to compare date in that way in Rspec is:

database_start_date.should be_within(1).of(start_date)

One gotcha is that Ruby Time objects have nanosecond precision, but most databases have at most microsecond precision. The best way to get around this is to stub Time.now (or use timecop) with a round number. Read the post I wrote about this: http://blog.solanolabs.com/rails-time-comparisons-devil-details-etc/

Depending on your specs, you might be able to use Rails-native travel helpers:

# in spec_helper.rb
config.include ActiveSupport::Testing::TimeHelpers

start_date ||= Time.current.change(usecs: 0)
end_date = start_date + goal_months.months
travel_to start_date do
  # Clone here  
end
expect(clone.start_date).to eq(start_date)

Without Time.current.change(usecs: 0) it's likely to complain about the difference between time zones. Or between the microseconds, since the helper will reset the passed value internally (Timecop has a similar issue, so reset usecs with it too).

My initial guess would be that the value of Time.now is formatted differently from your database value.

Are you sure that you are using == and not eql or be? The latter two methods use object identity rather than comparing values.

From the output it looks like the expected value is a Time, while the value being tested is a DateTime. This could also be an issue, though I'd hesitate to guess how to fix it given the almost pathological nature of Ruby's date and time libraries ...

One solution I like is to just add the following to spec_helper:

class Time
  def ==(time)
    self.to_i == time.to_i
  end
end

That way it's entirely transparent even in nested objects.

Adding .to_datetime to both variables will coerce the datetime values to be equivalent and respect timezones and Daylight Saving Time. For just date comparisons, use .to_date.

An example spec with two variables: actual_time.to_datetime.should == expected_time.to_datetime

A better spec with clarity: actual_time.to_datetime.should eq 1.month.from_now.to_datetime

.to_i produces ambiguity regarding it's meaning in the specs.

+1 for using TimeCop gem in specs. Just make sure to test Daylight Saving Time in your specs if your app is affected by DST.

Our current solution is to have a freeze_time method that handles the rounding:

def freeze_time(time = Time.zone.now)
  # round time to get rid of nanosecond discrepancies between ruby time and
  # postgres time
  time = time.round
  Timecop.freeze(time) { yield(time) }
end

And then you can use it like:

freeze_time do
  perform_work
  expect(message.reload.sent_date).to eq(Time.now)
end