RSpec is doing a Samoa on me

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! :frowning:

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 :slight_smile:

Regards,
Iain

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs