Test integracji TimeWithZone i Time.zone.now kończy się niepowodzeniem.

Question

W metodzie sterownika ustawiam zmienną użytkownika activation_sent_at równą Time.zone.now, gdy wiadomość aktywacyjna jest wysyłana do tego użytkownika. Na serwerze programistycznym to wydaje się działać (chociaż wyrażenia czasu w mojej aplikacji są 2 godziny opóźnione w czasie lokalnym mojego komputera).

Chcę dołączyć test integracyjny, który sprawdza, czy rzeczywiście ustawiono activation_sent_at. Więc zawarte linię:

assert_equal @user.activation_sent_at, Time.zone.now 

to jednak wywołuje błąd:

No visible difference in the ActiveSupport::TimeWithZone#inspect output. 
You should look at the implementation of #== on ActiveSupport::TimeWithZone or its members. 

myślę, że to sugeruje użyć innego wyrażenia dla Time.zone.now w moim teście. Przyjrzałem się różnym źródłom, w tym http://api.rubyonrails.org/classes/ActiveSupport/TimeWithZone.html, ale nie jestem pewien, co tutaj zrobić. Wszelkie sugestie, co może być przyczyną tego błędu?

Dodatkowe informacje: Dodanie puts Time.zone.now i puts @stakeholder.activation_sent_at potwierdza, że ​​dwa są równe. Nie wiem, co generuje błąd/błąd.

Answer 1

Problem polega na tym, że 2 daty są bardzo blisko siebie, ale nie są takie same. Można użyć assert_in_delta

assert_in_delta @user.activation_sent_at, Time.zone.now, 1.second

Dla rspec, podobne podejście byłoby użyć be_within:

expect(@user.activation_sent_at).to be_within(1.second).of Time.zone.now

Answer 2

Problemem jest to, że czasy są bardzo blisko, ale nie dość równe. Są prawdopodobnie wyłączone o kilka ułamków sekundy.

Jednym z rozwiązań takich problemów jest klejnot testowy o nazwie timecop. Daje możliwość wyśmiewania Time.now, dzięki czemu tymczasowo zwróci określoną wartość, którą można wykorzystać do porównań.