Question

I’ve got a large rails test suite and I’m using Timecop just once.

it "should not include votes from today" do
  assert_equal 8, @answer.todays_score
end

it "should include today's votes tomorrow" do
  Timecop.travel(Date.today + 1) do
    assert_equal 10, @answer.yesterdays_score
  end
end

These specs pass when I run the full suite with:

rake

or

rake spec

however Timecop.freeze doesn’t work if I try to run a smaller set or the individual spec. That is, both the following will fail:

rspec ./spec/models/answers_spec.rb

rake spec:models

Any ideas? Am I missing something about the interaction betwen ruby / rspec / rake and maybe bundler?. (for the record — I get the same results when I run all of the above preceded with ‘bundle execute’).

I’m including my Gemfile and spec.helper in case this clarifies anything.

Gemfile:

gem 'rails', '3.2.8'
gem 'omniauth'
gem 'omniauth-twitter'
gem 'omniauth-facebook'
gem 'haml-rails'
gem 'sass'
gem 'chronic'
gem 'chronic_duration'
gem 'heroku'
gem 'pg', '0.13.1'
gem 'jquery-rails'
gem 'jquery_mobile_rails', "1.1.0"
gem "bcrypt-ruby", :require => "bcrypt"
gem 'rails_autolink'

group :assets do
  gem 'sass-rails'
  gem 'coffee-rails'
  gem 'uglifier'
end

group :development, :test do
  gem 'timecop'
  gem 'ruby-prof' 
  gem 'factory_girl_rails'
  gem 'rspec-rails'  
  gem 'capybara'
  gem 'mocha'
end

spec_helper.rb:

require 'rubygems'
ENV["RAILS_ENV"] ||= 'test'
require File.expand_path("../../config/environment", __FILE__)
require 'rspec/rails'
require 'capybara/rails'
require 'rspec/autorun'
require 'mocha'

Dir[Rails.root.join("spec/support/**/*.rb")].each {|f| require f}

RSpec.configure do |config|
  config.mock_with :mocha
  config.use_transactional_fixtures = true
  config.infer_base_class_for_anonymous_controllers = false
  config.include(MailerMacros)  
  config.before(:each) { reset_email }
end

Answer 1

I believe that if you try running rake spec enough times there will be times when it will fail. There is probably a time dependency problem somewhere that aggravates when the time gap between tests is smaller (just a hunch).

My guess is that @answer has a time field which has been instantiated before it was called in the Timecop block. I think that you would have to create @answer within another Timecop.freeze block so that there is no second-guessing about @answer‘s time origins.

Inspect your before blocks. (any before :all blocks?) I think that when running smaller test suites commands in the before block causes the object to be instantiated with the undesired timestamp before Timecop kicks in. If there is a before :all stuff from previous tests might have caused changes too.