# Allow to freeze the time in scope of tagged example. Thanks to it, we can simply freeze time by marking a test with :stop_the_time tag: include ActiveSupport::Testing::TimeHelpers We made usage of the around RSpec hook to define a custom test helper (placed within spec/support/time_helper.rb file): # Allow to freeze the time in scope of tagged example.Ĭonfig.around(:each, :stop_the_time) do |example| To learn from our own mistakes, along the way we decided to unify our approach to time across all the test files. To provide an example, let’s update the Building#clock? test: include ActiveSupport::Testing::TimeHelpers inside spec/rails_helpers.rb file:Ĭonfig.include ActiveSupport::Testing::TimeHelpers. To have the method available across tests files you need to include it, e.g. Replace them by equivalent from the TimeHelpers module.We found several places where time had been frozen but wasn’t unfrozen afterwards □ Find all occurrences of timecop methods in test files.They provide the same functionalities timecop provides. In addition to the freeze_time there are also other useful methods grouped into the ActiveSupport::Testing::TimeHelpers module. According to its release note it a dds freeze_time helper which freezes time to Time.now in tests. Otherwise Timecop::SafeModeException is raised □.Īnd that had been, more or less, an approach we took until Ruby on Rails 5.2 was released. Today I learned that there is a Timecop.safe_mode method which forces using the block syntax. To make the failing tests, we can freeze time: describe Building doįinished in 0.62 seconds (files took 2.63 seconds to load)Ī common issue I have observed over time is calling eeze without a block and forgetting about Timecop.return to put time back the way it was. eeze to freeze time (which optionally accepts a block),.The timecop gem provides a set of useful method to handle such cases without a need for complicated mocking time-related objects, inter alia: You know what they say – time flies when you’re having fun □. It 'returns time displayed by the clock' doĮxpect(described_).to eq Īnd, surprisingly or not, the test didn’t pass: expected: 19:26:14.958265000 +0000 To cover the #clock method with rspec we could use the below lines: describe Building do To better illustrate when the gem may be useful, let’s write down some naive lines of code representing a building with a clock ⏰: class Building It provides a unified method to mock Time.now, Date.today, and DateTime.now in a single call. Among Rubyists, the most popular gem which provides handy helpers to this problem is called timecop:Ī gem providing “time travel”, “time freezing”, and “time acceleration” capabilities, making it simple to test time-dependent code. Sooner or later each of us encounters a situation where a method depends on time. Please remember about unfreezing time in tests, regardless of an approach you choose. Nested calls to Timecop#travel and Timecop#freeze are supported - each block will maintain its interpretation of now.TLDR Since Ruby on Rails 5.2 timecop gem can be replaced by built-in methods defined within the ActiveSupport::Testing::TimeHelpers module.a single integer argument that is interpreted as an offset in seconds from Time.now.individual arguments (year, month, day, hour, minute, second).Timecop api allows arguments to be passed into #freeze and #travel as one of the following:.No dependencies, can be used with any ruby project.Scale time by a given scaling factor that will cause time to move at an accelerated pace.Travel back to a specific point in time, but allow time to continue moving forward from there.A gem providing "time travel" and "time freezing" capabilities, making it dead simple to test time-dependent code.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |