Hacker News Reader

Comment by Wowfunhappy | Hacker News Reader

Is there a good way to test for bugs like this during development? Since it’s not particularly realistic to pause development for two months to see what a given build does after that long.

View on HN

Our company does soak/longevity testing. Typically we'll take a build and let it run for a few weeks during development to find memory leaks. Then the final release enters our longevity lab where we put it under some amount of load and let it run until the device or VM is retired. It won't necessarily find the bug before final release, we could either recall that version or submit an immediate maintenance version that fixes the issue once discovered.

Software will always have bugs, we've chosen to approach it as "find the bugs before the customer" rather than "stomp out every possible bug". Because you are right, we don't get 2 months to pause and fix bugs, and also customers will always do some crazy configuration or workload you didn't have a test case for.

That's pretty cool. What industry are you in that y'all are willing to invest resources for such an exercise?

When you start development version of Windows CE or Windows Embedded (don’t remember exactly which one) tick count timer wasn’t set to zero but max dword minus number of milliseconds in two minutes. So counter overflows in 2 minutes after system start. This is very smart way to catch such bugs.

The same way you test for leap-year bugs, write unit-tested code that tests all your boundary conditions.

Hmm 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.

The 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'?

Reply on news.ycombinator.com