-
Notifications
You must be signed in to change notification settings - Fork 21.8k
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
Conversation
# 2 days from today | ||
|
||
travel_back | ||
travel_to 5.days.from_now |
There was a problem hiding this comment.
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
?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
da79bfb
to
c7a1a6e
Compare
end | ||
|
||
MSG | ||
raise travel_to_nested_block_call |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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 :)
c7a1a6e
to
b3daa50
Compare
@vipulnsward hey, you still interested in making this happen? 😁 |
Oh yes. Its still on my radar. |
6860c0f
to
4eed2a7
Compare
Alright, ready for another round. |
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) |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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 😁
How do we fare with putting |
This also breaks Active Record's tests so there's probably a place where we use nested travels 😁 |
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
4eed2a7
to
919e705
Compare
Nice! ❤️ |
r? @rafaelfranca