规范在本地传递,但无论何时在CircleCI上运行,预期与实际之间都会略有不匹配.
规范看起来像这样：
describe '#my_method' do
it 'returns created_at' do
object = FactoryGirl.create(:something)
expect(foo.bar(object)).to eq object.created_at
end
end
当它在本地传递时,在CircleCI上,我不断得到类似的错误消息.
以下是示例：
(1)
expected: 2015-05-09 10:42:59.752192641 +0000 got: 2015-05-09 10:42:59.752192000 +0000
(2)
expected: 2015-05-08 10:16:36.777541226 +0000 got: 2015-05-08 10:16:36.777541000 +0000
从错误中,我怀疑CircleCI正在计算时间戳值,但我没有足够的信息.有什么建议？
解决方法
与此同时,让这些测试通过的解决方法只是确保您在这样的测试中使用的时间戳使用模拟时间的库(如timecop)进行舍入.
describe '#my_method' do
it 'returns created_at' do
# CircleCI seems to round milliseconds,which can result in
# slight differences when serializing times.
# To work around this,ensure the millseconds end in 000.
Timecop.freeze(Time.local(2015)) do
object = FactoryGirl.create(:something)
expect(foo.bar(object)).to eq object.created_at
end
end
end
更新：基于CircleCI的初始响应,上述方法实际上是他们推荐的方法.然而,他们还没有能够解释为什么实际上正在进行舍入.
更新2：看起来这与不同系统之间的精度差异有关.我个人在OS X上看到了这个问题.以下是Circle的回复：
From what I know,Time.now actually has different precision on OS X
and Linux machines. I would suppose that you will get the exact same
result on other Linux hosts,but all OS X hosts will give you the
result without rounding. I might be wrong,but I recall talking about
that with another customer. Mind checking that on a VM or an EC2
instance running Linux?In the Time reference you can search for precision on the page—the
round method can actually adjust the precision for you. Would it be an
option for you to round the time in the assertion within the test?
我还没有尝试过他们的建议,但是这似乎提供了一个解释以及一个额外的解决方法(在测试中舍入断言),不需要timecop.