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 Maxwell Chief Technologist E Factor Media // FN Interactive kyle@efactormedia.com 1-866-263-3261
On 2/6/06, Kyle Maxwell <kyle@kylemaxwell.com> 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.
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 On 07/02/06, Kyle Maxwell <kyle@kylemaxwell.com> 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. > > -- > Kyle Maxwell > Chief Technologist > E Factor Media // FN Interactive > kyle@efactormedia.com > 1-866-263-3261 > > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails > > >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060207/360cd09e/attachment.html
On Feb 6, 2006, at 10:52 PM, Kyle Maxwell 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)> > -- > Kyle Maxwell > Chief Technologist > E Factor Media // FN Interactive > kyle@efactormedia.com > 1-866-263-3261 > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails-- Daryl "We want great men who, when fortune frowns, will not be discouraged." -- Colonel Henry Knox, 1776
On 2/7/06, Daryl Richter <daryl@eddl.us> wrote:> > On Feb 6, 2006, at 10:52 PM, Kyle Maxwell 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) > > > > > > -- > > Kyle Maxwell > > Chief Technologist > > E Factor Media // FN Interactive > > kyle@efactormedia.com > > 1-866-263-3261 > > _______________________________________________ > > Rails mailing list > > Rails@lists.rubyonrails.org > > http://lists.rubyonrails.org/mailman/listinfo/rails > > -- > Daryl > > "We want great men who, when fortune frowns, will not be discouraged." > -- Colonel Henry Knox, 1776 > > > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > 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 Maxwell Chief Technologist E Factor Media // FN Interactive kyle@efactormedia.com 1-866-263-3261