Topic: Brain freeze ... testing updated/created_at parameters...

Is there a best practice for testing how the magic created_at/updated_at timestamped files are updated?

I have a standard has_many :through, with the join model having the created_at as an extra parameter.  This join model related "couples" to "events" through "event_registrations".  The normal interaction is that from a couple-based form a list of event_ids is returned (checkboxes).  I'll compare the list of event_ids to the saved list to derive the events-to-add registrations for and the events-to-delete registrations for.  (This part is easy...)  And while my initial implementation is correct, the tests don't properly constrain it -- I need to add the test that if an event was already registered it doesn't change the created_on.  (Ie, the implementation shall not do a "drop all current registration for the couple and then add the selected list").

I could hard-code a timestamp into the fixture, cache the result in the test and compare.  I think this is the easiest, and I don't really need the flexibility of that timestamp migrated (like in the future-proof book of AWDwR).  Does the timestamp/cahche/compare method sound right to you?  Is there a better way?


My RoR journey  -- thoughts on learning RoR and lessons learned in applying TDD and agile practices.

Re: Brain freeze ... testing updated/created_at parameters...

Not sure how best to handle this kind of test but I'm running up against a similar one. Mine involves the sequence:

1. User arrives, session cookie set with expiration 2 minutes
2. User browses, session cookie slid accordingly
3. User loses interest, drinks coffee, answers phone, session cookie expired

How do you test this without resorting to something like Selenium?

Re: Brain freeze ... testing updated/created_at parameters...

In your case it looks like you are trying to test too much at once.  From what I see that should be three separate functional/controller tests, not the one integration test as written.  No whether you can a dynamic fixture depends on how you're modeling session cookies -- client-side only, server-side only, or both, etc.  However...

Test 1a. User Login establishes a cookie with expiration of 2 minutes.

Test 1b: User activity updates session expiration

Test 2: Expired Cookie

Test 2 is easily handled by a dynamic configuration (fixture/faked cookie as needed).  Simple load it as <%= 2.minutes.ago -%>

Tests 1a&b are require basically the same handling.  And I think require either i) cached time before/after or ii) mocking out the now() (or introducing a Time class for easier mocking).  Option i) is probably easier, but you'll have to accept some slightly "flex" in your test -- ie test that expiration time is < cached_now + 2.minutes + n.seconds  (need some extra execution time).  If you mock out now so that you now what it will return, then you can exactly constrain your test...

My RoR journey  -- thoughts on learning RoR and lessons learned in applying TDD and agile practices.