Changing the system date for functional tests

Rails
1

Is there a way to simulate the functional test being called on
different days? In other words, the functional test may yield a
different result when run on different dates. I’d like to set the
system date in the test to see how the controller responds on different
dates.

Thanks!
Tom

2

Tom wrote:

Is there a way to simulate the functional test being called on
different days? In other words, the functional test may yield a
different result when run on different dates. I’d like to set the
system date in the test to see how the controller responds on different
dates.

Thanks!
Tom

You could get the system date from an object, and then use Mocks to
control what the object sends out.

3

Tom wrote:

Is there a way to simulate the functional test being called on
different days?

You can use a mocking/stubbing library to stub out Time.now in your
test setup.

Using FlexMock:
flexstub(Time).should_recieve(:now).and_return(Time.mktime(2007,1,1,12,49,00))

Another good library is Mocha.

Dan M.

4

Dan M. wrote:

def my_day_of_the_week_based_method(the_time = Time.now)

do whatever with the_time

end

Don’t forget also adding to your /test/fixtures/model.yml files lines
like
<% 3.seconds.ago.to_s :db %>. Then your production code can rely on the
current time without passing it in. Your test fixture data will always
have
the correct values relative to the time of the test run.

–
Phlip
Redirecting... ← NOT a blog!!!

5

Dan M. wrote:

You can use a mocking/stubbing library to stub out Time.now in your
test setup.

Now that I think about it, this approach really is not good. Most
time-sensitive logic should be in your models. In all the methods you
write which use Time.now, you should pass it in to the method like
this:

def my_day_of_the_week_based_method(the_time = Time.now)

do whatever with the_time

end

Then for your unit tests, you can test it with different times easily.

In your functional tests which use this method in the model, you can
stub out the model method instead of stubbing out Time.now.

Either approach should work, but having the default Time.now parameter
in your model methods is a good practice.

Dan M.