• From: Boston, MA
  • Registered: 2006-06-17
  • Posts: 245

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?

Thanks

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

NielsenE's Website

  • cwd
  • First Class
  • Offline
  • Registered: 2006-06-17
  • Posts: 218

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?

  • From: Boston, MA
  • Registered: 2006-06-17
  • Posts: 245

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.

NielsenE's Website