Developers should not be force to choose between 2 APIs that achieve essentially the same goal.Īdditionally, Discourse uses mocha for all object mocking. It is confusing to have 2 ways of mocking time. There is no reason to have 2 time travel APIs
We already have a mocking library I don’t see why we need to introduce a second one.
#Timecop gem code
I don’t see why carry a whole gem dependency for 20 or so lines of code we control and can trivially debug. Make sure everything still passes by running tests 6. Hack away and add tests, not necessarily in that order 5. Heres the most direct way to get your work merged into the project.
Our API uses mocha which always cleans up, no need to remember anything. timecop is maintained by travisjeffery, andwas created by jtrupiano. # forget this and you leak state into your test suite and break it Timecop API required consumers to remember to “unfreeze” time, which is called return before do Additionally, it had a bunch of fanciness we never used including date rounding, thread safe operation and time stack walking. Nesting can very quickly lead to incredibly hard to understand specs. The timecop gem offered too many options and too much flexibility, for example, want to do: avel 1.day.ago do The catalyst for the change was 3 days of an unstable test suite, caused by misuse of the Timecop library. I guess the first thing people may ask when confronted with this "Sam!? Wheels why reinvent them? Cheese, why move it? I manually changed every usage of Timecop in both core and core plugins to use the new pattern. So most changes are as simple as: eeze(1.day.from_now) do Migrating from timecop to our freeze_time helper should be a breeze as it already supports the block form.
TrackTimeStub.stubs(:stubbed).returns(true) Raise "nested freeze time not supported" if TrackTimeStub.stubbedĭate.stubs(:today).returns(datetime.to_date) If you're testing things like trials, calendar events, or other date and time calculations, these tools are invaluable for making sure your code works as expected.Yesterday I committed a change that removed the timecop gem and replaced it with these lines of code: class TrackTimeStub They can also accept a block to have time frozen only within the block.Īfter your tests, the stubs will be cleared out automatically so you don't have to worry about time changes affecting other tests. The "travel" and "travel_to" helpers can freeze time to a specific time in the past or future. is made possible through a partnership with the greater Ruby community. Become a contributor and improve the site yourself.
#Timecop gem install
Instantly publish your gems and then install them.Use the API to find out more about available gems. It will continue to return the exact same time until you call "unfreeze_time". is the Ruby community’s gem hosting service. It simply stubs out the Time.now, DateTime.now, and Date.today methods with the current time. The easiest place to start is to use the "freeze_time" method. Timecop is a popular gem you might have heard of or used in the past, but Rails actually comes with some built-in helpers. Rails provides some tools for helping test times and dates. Time always keeps ticking forward and dealing with timezones and other things can be a huge pain. Testing times and dates can be particularly tricky.
0 kommentar(er)
