On 11 May 2011, at 17:26, Chris Hulan 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 Candler wrote:

> I suggest you make a completely standalone rspec test until you find=20=

> 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 =3D 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 Jacobs wrote:

> As an aside, TimeCop is a great way to "freeze time" during unit tests =
that
> rely on Time.now:
>=20
> 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