in reply to Inscrutable test failure

My guess for the Sunday part was, that maybe time zones and/or daylight savings time are tripping you up, because the DST change is next weekend.

But as Tuesday would have to skip 25 hours to come close to a weekend day, I'm not exactly sure there, unless there also is an off-by-one error somewhere, so that you're unclear on whether a week starts with day 1 or day 0.

What you should learn from there is that you shouldn't just output the value from ->is_weekday in your test diagnostics but also the parameter given to it as input. I often use:

my $timestamp = UnixDate(ParseDate('last sunday'), "%s");
if (! is $obj->is_weekday($timestamp), 0, 'Sunday ($ts) is weekend')) 
+{
    diag "Last sunday = " . localtime($timestamp) . " ($timestamp)";
    diag "ParseDate('last sunday'):" . ParseDate('last sunday');
};

[download]

That way, you gather more data.

Another lesson to be learned would be to use static timestamps instead of timestamps depending on the time when a test is run. That way you get at least consistent failures/successes, but in your case, that would hide the error in your module(s).

Replies are listed 'Best First'.
Re^2: Inscrutable test failure
by dsheroh (Monsignor) on Oct 26, 2007 at 21:32 UTC
    Note that, in the tests, I'm setting the weekdays to 0011111 (Sun/Mon = weekend, Tue-Sat = weekday). Sunday and Tuesday were the chosen days to test specifically because that's where it places the transitions. So, if DST were to cause a one-hour error, it could affect Tuesday's status.

    Lesson learned about providing additional data in the messages (and I need to look up diag...), but I don't see how static timestamps would work any better, given that it's Friday right now in the US, but Saturday in Australia. The point of mucking around with Date::Manip was to get a time which is Sunday/Tuesday in the timezone of the machine running the test.

[reply]
[d/l]

      Static data only gives you reproducibility, not correctness. If you use a static timestamp for testing, and manage to get the DST changes out of the way (or in the past and thus at fixed dates), you will get consistent errors or successes in your test suite. This does not buy you correctness in the live program as the timestamps of the future and conditions on the production machines might well differ.

      Obviously, your client doesn't have a firm grip on the identical setup of test and production machines either as the (supposed) differences in timezones between test and production environment show, but maybe you still can get a VMWare image (or Xen, or Parallels or whatever the VM container du jour is) to run your tests in an environment as close to production as possible before approaching your client for installation.

[reply]
        I think I'm still missing some aspect of your suggestion to use a static timestamp in the tests. If I had it test is_weekday(1193435566) (that being the current time as I type this) and the test object was configured such that Friday is a weekday and Saturday is a weekend, then it would respond by saying that the static time is a weekday when run in the US and (correctly, but not consistently) that it is not a weekday when run in Australia.
[reply]
[d/l]

In Section Seekers of Perl Wisdom