Skip to content
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 and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

travel/travel_to travel time helpers, now raise on nested calls #24890

Merged
merged 1 commit into from
Jul 5, 2016

Conversation

vipulnsward
Copy link
Member

# 2 days from today

travel_back
travel_to 5.days.from_now
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Won't travel_back be what users want to call 90% of the times if they add a second travel_to in tests? Then shouldn't we just call it automatically for them? We could add an reset: false opt-out to travel and travel_to?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thats something I needed to discuss with @rafaelfranca . We had not discussed this scenario.
But essentially, we would like to achieve orderly calls. travel_to 2.days.from_now, travel_to 5.days.from_now, so makes sense.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I prefer to also use the block version here but without the nesting. Could you change it?

@vipulnsward vipulnsward force-pushed the travel-to-raise branch 2 times, most recently from da79bfb to c7a1a6e Compare May 21, 2016 08:50
end

MSG
raise travel_to_nested_block_call
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Something like this?

travel_to initial_expected_time
travel_to subsequent_expected_time
travel_to initial_expected_time
travel_to subsequent_expected_time
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need to do the initial subsequent dance a second time? Could do with some newlines :)

@kaspth
Copy link
Contributor

kaspth commented Jun 26, 2016

@vipulnsward hey, you still interested in making this happen? 😁

@vipulnsward
Copy link
Member Author

Oh yes. Its still on my radar.
Let me get to it soon.

@vipulnsward vipulnsward force-pushed the travel-to-raise branch 2 times, most recently from 6860c0f to 4eed2a7 Compare July 2, 2016 07:37
@vipulnsward
Copy link
Member Author

Alright, ready for another round.
r? @kaspth

@rails-bot rails-bot assigned kaspth and unassigned rafaelfranca Jul 2, 2016
inner_expected_time = Time.new(2004, 10, 24, 01, 04, 44)
travel_to outer_expected_time do
assert_nothing_raised do
travel_to(inner_expected_time)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this correctly reset the time outside of block? In other words, the inner travel_to pushes to the stack but do we pop all the way?

Shouldn't we test that here?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On the other hand I also find it strange that we support without a block travel within a block. Wasn't the point of this to prevent inner block calls?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, not unless you do an explicit travel_back, but that too will reset the complete state, we don't allow travel_back to previous state.

I think this is ok, since we explicity specify our preferred way is to not use multi-block or calls within a block.

end
end

assert_equal "\nCalling `travel_to` with a block, when we have previously already made a call to `travel_to`, can lead to confusing time stubbing.\n\nInstead of:\n\n travel_to 2.days.from_now do\n # 2 days from today\n travel_to 3.days.from_now do\n # 5 days from today\n end\n end\n\npreferred way to achieve above is:\n\n travel 2.days do\n # 2 days from today\n end\n\n travel 5.days do\n # 5 days from today\n end\n\n", error.message
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you can pass a Regex as the second argument to assert_raises which could simplify this check. Perhaps checking that part of the message is emitted is sufficient coverage rather than strictly asserting on the whole format 😁

@kaspth
Copy link
Contributor

kaspth commented Jul 2, 2016

How do we fare with putting travel in say setup and then using a travel with a block in a test method?

@kaspth
Copy link
Contributor

kaspth commented Jul 2, 2016

This also breaks Active Record's tests so there's probably a place where we use nested travels 😁

@vipulnsward
Copy link
Member Author

vipulnsward commented Jul 2, 2016

How do we fare with putting travel in say setup and then using a travel with a block in a test method?

That is exactly what broke the tests on Active Record. Preferred way is to not do that.

     as this can lead to confusing time stubbing.

     Instead of:

         travel_to 2.days.from_now do
           # 2 days from today
           travel_to 3.days.from_now do
             # 5 days from today
           end
         end

     preferred way to achieve above is:

         travel_to 2.days.from_now
         # 2 days from today

         travel_back
         travel_to 5.days.from_now
         # 5 days from today

Closes rails#24690
Fixes rails#24689
@kaspth kaspth merged commit 2dfb06a into rails:master Jul 5, 2016
@kaspth
Copy link
Contributor

kaspth commented Jul 5, 2016

Nice! ❤️

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants