3 ms·

But isn't this exactly the kind of thing that should be in a test plan? Run through all the possibly dates? I mean, didn't we learn our lesson from Y2K?

jerf 18y ago
Sure thing. We'll run it through all possible dates. Well, you know, some actions may only have problems on certain dates, so make that all possible actions on all possible dates. Well, you know, maybe the meridian counts. So, make that all possible actions on all possible dates in both the morning and the afternoon. Well, we better test that with all the pathological media files we've built up. So, make that all possible actions on all possible dates in the morning and the afternoon with every one of our three hundred test music files. Well... what if... In hindsight it's always easy to identify the test that would have revealed the problem. Given the ability of bugs to only manifest when five particularly tricky conditions occur (and let's not even TALK about race conditions!), it simply isn't possible to test them all exhaustively. Unit testing helps, sort of, because it can run through a matrix faster than a human can, but it's also dumber, and even unit testing can't exhaustively search a twelve-dimensional space in any reasonable period of time if it's anything more than binary values in those twelve dimensions. That said, for date processing code, this is definitely something I would have unit tested; that style of date processing is OK if you get it perfect, but definitely inherently problematic. One case where I did write a fairly exhaustive unit test was for billing code with a variable bill-on date; getting every single case exactly correct took me a long time. I was up to about three thousand permutations when I was done, and yeah, I'd see bugs that only struck if you signed up on the 31st of a month followed by a month of 30 days, for instance. Easy to miss if you're writing on a 15th. (And that code was probably thrown away... :( )
stcredzero 18y ago
At least analyze boundary conditions and special cases like leap years. Apparently, we don't learn the Y2K lesson. I keep hearing about date rollover bugs in the industry press. At a company I worked for, there was a 45 day internal clock rollover bug in one version of our virtual machine. AFAIK, no one ever ran into this, except for one system that controlled automated people-mover trains.

jerf 18y ago

Sure thing. We'll run it through all possible dates. Well, you know, some actions may only have problems on certain dates, so make that all possible actions on all possible dates. Well, you know, maybe the meridian counts. So, make that all possible actions on all possible dates in both the morning and the afternoon. Well, we better test that with all the pathological media files we've built up. So, make that all possible actions on all possible dates in the morning and the afternoon with every one of our three hundred test music files. Well... what if... In hindsight it's always easy to identify the test that would have revealed the problem. Given the ability of bugs to only manifest when five particularly tricky conditions occur (and let's not even TALK about race conditions!), it simply isn't possible to test them all exhaustively. Unit testing helps, sort of, because it can run through a matrix faster than a human can, but it's also dumber, and even unit testing can't exhaustively search a twelve-dimensional space in any reasonable period of time if it's anything more than binary values in those twelve dimensions. That said, for date processing code, this is definitely something I would have unit tested; that style of date processing is OK if you get it perfect, but definitely inherently problematic. One case where I did write a fairly exhaustive unit test was for billing code with a variable bill-on date; getting every single case exactly correct took me a long time. I was up to about three thousand permutations when I was done, and yeah, I'd see bugs that only struck if you signed up on the 31st of a month followed by a month of 30 days, for instance. Easy to miss if you're writing on a 15th. (And that code was probably thrown away... :( )

stcredzero 18y ago

At least analyze boundary conditions and special cases like leap years. Apparently, we don't learn the Y2K lesson. I keep hearing about date rollover bugs in the industry press. At a company I worked for, there was a 45 day internal clock rollover bug in one version of our virtual machine. AFAIK, no one ever ran into this, except for one system that controlled automated people-mover trains.