3 ms·
The same way you test for leap-year bugs, write unit-tested code that tests all your boundary conditions.
by LennyWhiteJr 7y ago
The same way you test for leap-year bugs, write unit-tested code that tests all your boundary conditions.
- mrlala 7y agoHmm that doesn't seem to be the same thing.. it's easy to test for leap-year, that's a simple case you can either test in the code or literally change your computer clock and let it rollover to see what happens. Very different than something which only happens after 50 days because obviously in small intervals it's not a noticeable bug.
- LennyWhiteJr 7y agoThe 50 days is arbitrary - the owners of GetTickTime should have written tests to handle what happens when the tick value rolls over. (Maybe they did, and allowing it to roll over was the desired behavior.) But more to the point - the consumers of GetTickTime should have also had tests to verify that the consuming code appropriately handles time rollovers. Granted, this was Win95 so I'll cut them some slack, but that should be standard procedure for any code that consumes an incrementing counter API. First question should always be - 'how will this code handle a rollover value'?