Add #unfreeze_time to ActiveSupport::Testing::TimeHelpers · Pull Request #33813 · rails/rails (original) (raw)

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Conversation23 Commits1 Checks0 Files changed

Conversation

This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters

[ Show hidden characters]({{ revealButtonHref }})

Add unfreeze_time alias method to travel_back in ActiveSupport::Testing::TimeHelpers.
The method unstubs Time.now and provides a method with a verb symmetry
to the existing freeze_time method that stubs it.
Ryan Davidson

This feature was discussed and approved in the Ruby on Rails > Core google group
https://groups.google.com/forum/#!topic/rubyonrails-core/cObTSEWG7XY
[ActiveSupport] feature proposal: Create #unfreeze_time to complement #freeze_time in ActiveSupport::Testing::TimeHelpers

Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @kaspth (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

This repository is being automatically checked for code quality issues using Code Climate. You can see results for this analysis in the PR status below. Newly introduced issues should be fixed before a Pull Request is considered ready to review.

Please see the contribution instructions for more information.

Hey!

The motivation for this method is that users can write freeze/unfreeze instead of the equivalent freeze/travel_back, because it reads better.

In that sense, I believe we'd need just an alias here, no need to duplicate code and docs.

Hey @fxn, if I make it an alias how is this recognised in the documentation generated? My concern that to do something like the following may mean the method unfreeze_time may not receive documentation for users to understand it and how to use it. Do you know how Rails handles documenting aliases?

Returns the current time back to its original state, by removing the stubs added by

  # +travel+ and +travel_to+.
  #
  #   Time.current # => Sat, 09 Nov 2013 15:34:49 EST -05:00
  #   travel_to Time.zone.local(2004, 11, 24, 01, 04, 44)
  #   Time.current # => Wed, 24 Nov 2004 01:04:44 EST -05:00
  #   travel_back
  #   Time.current # => Sat, 09 Nov 2013 15:34:49 EST -05:00
  def travel_back
    simple_stubs.unstub_all!
  end

  alias_method :unfreeze_time, :travel_back

I will plan to make the change to use an alias sometime this week and update this PR.

Aliases are extensively used for cases like this when you want to provide the same implementation under a different name for the sake of having a different name. The documentation says the method is an alias of another method, and links to that one. Users understand. See for example titlecase.

You can grep the project for alias_method and see other examples.

@fxn That was helpful to point me to an existing alias example in the rails codebase. I have now updated the code in this PR with an alias for unfreeze_time.

In order to test the aliased method, I used a simple method comparison in the test suite. How does this suit the existing way of testing alias methods in rails?

def test_time_helper_unfreeze_time assert_equal method(:unfreeze_time), method(:travel_back) end