rspec users - Jan 2009 - Mocking/Stubbing ActiveRecord.config.default_timezone

In tracking down a bug in AuthLogic I realized that I had made the same
error in one of my libraries.  Knowing what the error was made creating
a test to expose it (using cucumber) rather trivial.  However, it has
occurred to me that this sort of issue is far more subtle than I first
appreciated.  So, I am looking for some opinions on how to test for this
sort of thing in a more general sense.

At issue is the setting of config values in environment.rb files and
their influence on user code.  In the specific case I encountered this
code demonstrates the essence of the situation:

    def active_row?
      time_now = DateTime.now
      return true if  (effective_from <= time_now and
                      (not superseded_after or superseded_after >time_now ))
      return false
    end

The error is that the time_now assignment is not testing whether or not
the default AR time is utc.  The correct code is:

    def active_row?
      if self.class.default_timezone == :utc
        time_now = DateTime.now.utc
      else
        time_now = DateTime.now
      end
      return true if  (effective_from <= time_now and
                      (not superseded_after or superseded_after >time_now ))
      return false
    end

My question is:  How does one vary the config.default_timezone, or any
configuration value for that matter, in a cucumber step definition or
RSpec test?
-- 
Posted via http://www.ruby-forum.com/.

On Mon, Jan 26, 2009 at 7:23 AM, James Byrne <lists at ruby-forum.com>
wrote:
>  return true if  (effective_from <= time_now and
>                      (not superseded_after or superseded_after >= 
time_now
> ))
>      return false
>
This has nothing to do with your question - just a style suggestion:

 effective_from <= time_now and (superseded_after.nil? or
superseded_after
>=  time_now)
No need to use ''return''. And you don''t want to check
if superseded_after is
false - just nil (if it''s false, there''s a bug that would be
hidden by ''not
superseded'').

Carry on. :)

///ark
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/rspec-users/attachments/20090126/90bc6f5c/attachment.html>

Mark Wilden wrote:
> On Mon, Jan 26, 2009 at 7:23 AM, James Byrne <lists at
ruby-forum.com>
> wrote:
> 
> This has nothing to do with your question - just a style suggestion:
> 
>  effective_from <= time_now and (superseded_after.nil? or 
> superseded_after = time_now)
> 
> No need to use ''return''. And you don''t want to
check if superseded_after
> is false - just nil (if it''s false, there''s a bug that
would be hidden by
> ''not superseded'').
> 
I prefer the style of explicit returns.  It makes intent unambiguous. 
Your point wrt nil? is well taken and I have modified the code to use 
this idiom.
-- 
Posted via http://www.ruby-forum.com/.

On Mon, Jan 26, 2009 at 9:06 AM, James Byrne <lists at ruby-forum.com>
wrote:
>
> I prefer the style of explicit returns.  It makes intent unambiguous.
>
The thing is that the Ruby idiom is to avoid unnecessary returns. Because of
this, using them actually makes code harder to read, because you have to
read it more carefully to see if they''re being used for a legitimate
reason.

Just one opinion.

///ark
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/rspec-users/attachments/20090126/4bb494db/attachment.html>

Mark Wilden wrote:
>
> 
> The thing is that the Ruby idiom is to avoid unnecessary returns. 
> Because of  this, using them actually makes code harder to read,
> because you have to read it more carefully to see if they''re being
> used for a legitimate reason.
If the method is short, the code simply falls through, and I am not 
doing anything particularly subtle with the result, then I follow the 
convention of no explicit return.  If a method requires at least one 
explicit return then I code all possible outcomes as returns.  In such a 
case, one _should_ be reading the code more carefully, particularly if 
one is writing it.

But, we digress.  I am still looking for suggestions on recommended 
approaches to testing application code that is dependent upon 
environment.rb config values.

-- 
Posted via http://www.ruby-forum.com/.