Forum: RSpec Mocking/Stubbing ActiveRecord.config.default_timezone

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
171ea139761951336b844e708d1547ab?d=identicon&s=25 James Byrne (byrnejb)
on 2009-01-26 16:23
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?
48641c4be1fbe167929fb16c9fd94990?d=identicon&s=25 Mark Wilden (Guest)
on 2009-01-26 17:08
(Received via mailing list)
On Mon, Jan 26, 2009 at 7:23 AM, James Byrne <lists@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
171ea139761951336b844e708d1547ab?d=identicon&s=25 James Byrne (byrnejb)
on 2009-01-26 18:06
Mark Wilden wrote:
> On Mon, Jan 26, 2009 at 7:23 AM, James Byrne <lists@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.
48641c4be1fbe167929fb16c9fd94990?d=identicon&s=25 Mark Wilden (Guest)
on 2009-01-26 19:00
(Received via mailing list)
On Mon, Jan 26, 2009 at 9:06 AM, James Byrne <lists@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
171ea139761951336b844e708d1547ab?d=identicon&s=25 James Byrne (byrnejb)
on 2009-01-26 21:08
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.
This topic is locked and can not be replied to.