Next time you look at the release notes for a project, don’t skip over the less featured functionality. travel_to is a great addition to the framework that would’ve otherwise required dragging in additional dependencies. Test "sends reminders on tuesday for those scheduled on wednesday" do
While the change doesn’t look significant, it removed my need for the Timecop gem entirely.Īdditionally, the same test could be written as: test "sends reminders on tuesday for those scheduled on wednesday" do Supply a block automatically calls travel_back. Using the travel_to method with the example above results in the following: test "sends reminders on tuesday for those scheduled on wednesday" doīecause I’m using the travel_to method with a block, there’s no need to use the travel_back method to reset time back to the current time. The TimeHelpers test module adds the travel_to and travel_back methods to assist in stubbing Time.now and Date.today.
Towards the bottom, though, was a feature barely mentioned or written about: Like many, I looked over the release notes for Rails 4.1 and features like Spring, secrets, ActionMailer previews, and ActiveRecord enums jumped out at me.
He mentioned them in one of our various conversations about testing (he’s writing a book titled What Do I Test?). I think I first heard about some additional testing methods from my friend Eric Steele. Note: Chronic is a gem that helps create dates/times by using standard language. eeze Chronic.parse("4/15/14") doĪssert_equal 3, ActionMailer:: This is important because without control over the time, flakey tests can emerge in your codebase. Prior to utilizing the changes in Rails 4.1, one of my tests looked like: test "sends reminders on tuesday for those scheduled on wednesday" do Timecopis the go-to gem for testing time-dependent code, as it allows you to manipulate the current time during test runs. However, dragging in another gem was the last thing I wanted to do for something relatively simple. Timecop performed valiantly and did more than I ever needed (I generally only used the freeze method). This new helper method forces the current time to whatever you specify, allowing you to make asserts against a historical time, or week in my case. With the release of Rails 4.1, the time stubbing method travel_to was added. Naturally, I dragged in the timecop gem to handle freezing time, so my I could properly assert that certain events took place in the tests. The app is heavily dependent on times and recurring events (weekly).
#Rspec timecop code
Here's the code I'm using in features/support/unfreeze_time.rb: After do Timecop.I’ve recently had the good fortune of working on a greenfield Rails app. This can be achieved with a Cucumber hook. Sure enough, in the comments Pat Maddox suggested a neat Cucumber step to solve this problem: Given /^the date is "(*)"$/ do |date_string| eeze Chronic.parse("# at noon") end This step definition allowed me to rewrite the scenario as: Scenario: See yesterday's date on yesterday's tracker Given the date is "28 July 2010" When I am on the tracker page for yesterday Then I should see "27 July 2010" Et viola, no time bomb! **Update 2** As supaspoida highlighted in the comments, it's also necessary to turn off Timecop after the scenario has been executed. I recalled reading about a similar problem in a (). Clearly, a brittle test like the one above is no good. This is where Behavior Driven Development (BDD) frameworks, like RSpec, can be both exceptionally powerful and frustrating. I'm using Cucumber to capture my features, and I wanted to say something like this: Scenario: See yesterday's date on yesterday's tracker When I am on the tracker page for yesterday Then I should see "27 July 2010" Where "the tracker page for yesterday" maps to a path like: tracker?date= Because today's date is the 28th July 2010, this test will pass today, but never again after today. Today I found that I needed to write some date-sensitive tests for a little Rails app I'm building.
0 kommentar(er)
