Closed rgaufman closed 1 year ago
Update, if I add this to the environments test.rb file, it does something different, but still doesn't work:
Rails.application.configure do
config.after_initialize do
# Set Time.now to Feb 12, 2023 10:05:00 AM (at this instant), but allow it to move forward
t = Time.local(2023, 2, 12, 10, 5, 0)
Timecop.travel(t)
end
It does then seem to stub the date, but it still fails like this:
- :state_params_updated_at=>2023-02-12 10:05:00.377149999 +0000}},
+ :state_params_updated_at=>2023-02-12 10:05:00.365396000 +0000}},
Any ideas?
Hey @rgaufman without seeing all your code and understanding the environment you're running in I can't troubleshoot this, but a couple things to consider: time cop is only stubbing out the time for the ruby process in your test. If DevicePacketLossJob is running through some queueing system in another process, timecop isn't doing anything there. Also timecop can't affect times that your DB system is generating, so things like current_timestamp running in SQL won't be affected. You probably know this stuff anyway, but just double check that delayed job or sidekiq is running DevicePacketLossJob inline in the spec process.
Going to close this since we haven't gotten actionable with this and no updates. Re-open if you need to.
I have this spec:
I have this callback that sets the time in the database in app/models/application_record.rb:
When I run it the spec, I see:
So it seems the Time.now.utc inside of app/models/application_record.rb is returning the time now and is not the expected time from Timecop.
Any ideas?
I'm using latest versions of everything, just done bundle update: