[ANN] RailsCron 0.2.2, please update

Rails
1

I updated RailsCron to fix some threading issues with ActiveRecord.
Please update if you were on 0.2.1. Also, I am still working on a
good unit test strategy (its tricky because I would think that the
tests must occur over a lot of time), but haven’t had/made time to
give it its due. If you have suggestions, please let me know.

–
Kyle M.
Chief Technologist
E Factor Media // FN Interactive
[email protected]
1-866-263-3261

2

On 2/6/06, Kyle M. [email protected] wrote:

I updated RailsCron to fix some threading issues with ActiveRecord.
Please update if you were on 0.2.1. Also, I am still working on a
good unit test strategy (its tricky because I would think that the
tests must occur over a lot of time), but haven’t had/made time to
give it its due. If you have suggestions, please let me know.

Saw a lot of this, on a larger scale, while testing systems prior to
Y2K.
How about refactoring lines like this:
now = Time.now.to_i
…to be method calls to a stub, rather than bare Time.now?
Then, during test setup, you can push in a different object that
returns times you specify in advance.

I suppose you could also do this, but it’s bad scary:
irb(main):001:0> class Time
irb(main):002:1> class << self
irb(main):003:2> attr_writer :fake_time
irb(main):004:2> alias_method :right_now, :now
irb(main):005:2> end
irb(main):006:1>
irb(main):007:1* def self.now
irb(main):008:2> @fake_time || self.right_now
irb(main):009:2> end
irb(main):010:1> end
=> nil
irb(main):011:0> t = Time.now - 800000
=> Sat Jan 28 17:01:44 Eastern Standard Time 2006
irb(main):012:0> Time.fake_time = t
=> Sat Jan 28 17:01:44 Eastern Standard Time 2006
irb(main):013:0> Time.now
=> Sat Jan 28 17:01:44 Eastern Standard Time 2006
irb(main):014:0> Time.fake_time = nil
=> nil
irb(main):015:0> Time.now
=> Mon Feb 06 23:15:42 Eastern Standard Time 2006
irb(main):016:0>

It’s actually kinda insane that you can do that. I like it.

3

Hi Kyle

I have no experience (yet!) with unit testing of “scheduled things” in
ruby
and ror, but on other platforms, I’m often using a dedicated class to
provide the time to other classes. I do this in an explicit way (such as
passing the instance of time provider at construction time) rather than
implicit (that would be the more scary way Wilson describes!).

When I write the corresponding test, I pass a mocked version of this
class
instead, and simulate the change of time on the time provider, then
check
how the system under test reacts.

This way the test doesn’t have to run a long time.

Have a look there
http://www.pragmaticprogrammer.com/articles/may_02_mock.pdf

The paragraph entitled “mock objects” lists the most common cases where
it’s
relevant to use a mock object.

HTH

Thibaut

[blog] http://www.dotnetguru2.org/tbarrere

4

On Feb 6, 2006, at 10:52 PM, Kyle M. wrote:

I updated RailsCron to fix some threading issues with ActiveRecord.
Please update if you were on 0.2.1. Also, I am still working on a
good unit test strategy (its tricky because I would think that the
tests must occur over a lot of time), but haven’t had/made time to
give it its due. If you have suggestions, please let me know.

Are you still at http://opensvn.csie.org/rails_cron/trunk?

I just svn up’ped and didn’t get any changes. (Revision: 5)

http://lists.rubyonrails.org/mailman/listinfo/rails
–
Daryl

“We want great men who, when fortune frowns, will not be discouraged.”
– Colonel Henry Knox, 1776

5

On 2/7/06, Daryl R. [email protected] wrote:

Rails mailing list
[email protected]
http://lists.rubyonrails.org/mailman/listinfo/rails

I moved it to svn.kylemaxwell.com/rails_cron/trunk … I need to pull
down the csie repository.

–
Kyle M.
Chief Technologist
E Factor Media // FN Interactive
[email protected]
1-866-263-3261