无法用 RSpec 比较时间

我发现使用 be_within 默认 rspec 匹配器更优雅：

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

---

Ruby Time 对象比数据库保持更高的精度。当从数据库中读回该值时，它只保留到微秒精度，而内存中的表示精确到纳秒。

如果您不关心毫秒差异，则可以在期望的两侧执行 to_s/to_i

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

或者

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

请参阅 this 了解有关时间不同原因的更多信息

---

旧帖子，但我希望它可以帮助任何进入这里寻求解决方案的人。我认为手动创建日期更容易、更可靠：

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

这样可以确保存储的日期是正确的，而无需执行 to_x 或担心小数。

---

是的，因为 Oin 建议 be_within matcher 是最佳做法

...而且它还有更多用例 -> http://www.eq8.eu/blogs/27-rspec-be_within-matcher

但是另一种处理方法是使用 Rails 内置的 midday 和 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

现在这只是为了演示！

我不会在控制器中使用它，因为您正在对所有 Time.new 调用进行存根 => 所有时间属性都将具有相同的时间 => 可能无法证明您试图实现的概念。我通常在与此类似的组合 Ruby 对象中使用它：

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

但老实说，即使在比较 Time.now.midday 时，我也建议坚持使用 be_within 匹配器！

所以是的，请坚持使用 be_within 匹配器；）

更新 2017-02

评论中的问题：

如果时间在哈希中怎么办？当一些 hash_1 值是 pre-db-times 并且 hash_2 中的相应值是 post-db-times 时，有什么方法可以让 expect(hash_1).to eq(hash_2) 工作？ –

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

您可以将任何 RSpec 匹配器传递给 match 匹配器（例如，您甚至可以执行 API testing with pure RSpec）

至于“post-db-times”，我猜你的意思是保存到数据库后生成的字符串。我建议将这种情况与 2 个期望解耦（一个确保哈希结构，第二个检查时间）所以你可以执行以下操作：

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)

但是，如果这种情况在您的测试套件中过于频繁，我建议您编写 own RSpec matcher（例如 be_near_time_now_db_string）将 db 字符串时间转换为 Time 对象，然后将其用作 match(hash) 的一部分：

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

---

我发现解决此问题的最简单方法是创建一个 current_time 测试帮助器方法，如下所示：

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

现在时间总是四舍五入到最接近的毫秒，比较简单：

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

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

---

您可以使用 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)

---

因为我在比较哈希，所以这些解决方案中的大多数对我都不起作用，所以我发现最简单的解决方案是简单地从我正在比较的哈希中获取数据。由于 updated_at 时间对我来说实际上并不能很好地测试它。

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

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

---

在 Rails 4.1+ 中，您可以使用 Time Helpers：

include ActiveSupport::Testing::TimeHelpers

describe "some test" do
  around { |example| freeze_time { example.run } }

  it "updates updated_at attribute" do
    expect { patch :update }.to change { @article.reload.updated_at }.to(Time.current)
  end
end

---