Hi,
RSpec is taking a day off the date in my tests:
RSpec:
let(:vtime_start){ Time.now - 10 }
(logged) => 2011-05-10 15:57:39 +0100
irb:
Time.now - 10
=> 2011-05-11 15:57:50 0100
system commandline:
$ date
=> Wed 11 May 2011 16:01:00 BST
irb again:
(Time.parse `date`.chomp) - 10
=> 2011-05-11 16:02:06 0100
I’m running ruby 1.9.2p0 (2010-08-18) [x86_64-darwin10.4.0], OSX 10.6.6,
RSpec 2.5.2
Is there something about the way Ruby deals with time that I should look
at, or have I done something stupid, or should I move this over to the
RSpec list?
Any help is much appreciated.
Regards,
Iain
I suggest you make a completely standalone rspec test until you find
what the problem is. It Works For Me [TM].
$ cat ert.rb
require ‘rspec’
describe “time” do
let(:vtime_start){ Time.now - 10 }
it “should work” do
puts Time.now
puts vtime_start
end
end
$ ruby -rubygems ert.rb
Wed May 11 16:31:42 +0100 2011
Wed May 11 16:31:32 +0100 2011
.
Finished in 0.00109 seconds
1 example, 0 failures
$ ruby -v
ruby 1.8.7 (2010-06-23 patchlevel 299) [x86_64-linux]
$ ls -1d /var/lib/gems/1.8/gems/rspec*
/var/lib/gems/1.8/gems/rspec-1.3.0
/var/lib/gems/1.8/gems/rspec-2.5.0
/var/lib/gems/1.8/gems/rspec-core-2.5.2
/var/lib/gems/1.8/gems/rspec-expectations-2.5.0
/var/lib/gems/1.8/gems/rspec-mocks-2.5.0
Could it be a problem with the logger you’re using? Try doing a puts
instead.
David
Could a change in another preceding test be leaking into this one?
I get that sometimes in my Python unit tests when I’m not careful
On 11 May 2011, at 16:52, David J. wrote:
Could it be a problem with the logger you’re using? Try doing a puts
instead.
Hi,
puts gave me this:
vtime_start: 2011-05-10 17:11:54 +0100
I only started logging it because the test was failing, and the code
it’s testing is simple, I can just run it in irb and it works, hence the
logging.
It’s very frustrating! 
Regards,
Iain
As an aside, TimeCop is a great way to “freeze time” during unit tests
that
rely on Time.now:
https://github.com/jtrupiano/timecop
On 11 May 2011, at 17:26, Chris H. wrote:
Could a change in another preceding test be leaking into this one?
I get that sometimes in my Python unit tests when I’m not careful
On 11 May 2011, at 16:34, Brian C. wrote:
I suggest you make a completely standalone rspec test until you find
what the problem is. It Works For Me [TM].
It shouldn’t (according to my wishes:) have been leaking stuff as each
test uses a fresh instance to test with and then sets the instance var
using instance_variable_set from the local vstart_time, but I
separated out the test, used a lets(:blah){ Blah.new } instead of a
before(:each){ @blah = Blah.new } and that got the time to work
properly, then put it back in.
Looking at the previous stuff I still can’t fathom why Time.now should
be affected the way it was. Surely Time.now is static and using a let
for vstart_time should insulate against leaks?
On 11 May 2011, at 17:51, David J. wrote:
As an aside, TimeCop is a great way to “freeze time” during unit tests that
rely on Time.now:
https://github.com/jtrupiano/timecop
I started using this and it’s made the tests a lot better.
Many thanks for all the help and suggestions, it’s made the swear jar a
lot poorer 
Regards,
Iain