3 ms·
Tests generally are the answer for the complex stuff in my experience. If it takes you more than a minute or so to check for the failure, then write a script t
by LyndsySimon 10y ago
Tests generally are the answer for the complex stuff in my experience.
If it takes you more than a minute or so to check for the failure, then write a script to automate it. Once that's done, you can just run the script at each iteration of bisect, and you'll save time in the long run. The bonus is that the script you've written to determine a failure case will also serve as a regression test so that the same bug won't be reintroduced in the future.
Adding the script as a regression test isn't always a possibility (you may not have a set of tests to add it to), but that's just a "value add" anyhow.
Oh, and if you don't have tests at all, that's a huge red flag. That should be remedied as quickly as possible.
- pvinis 10y agoI agree, but what if this script takes itself 10 min to run because it has to do lots of work? That's the slow cases I mean. As for tests, of course it's great to have tests, but how do you test if a streaming video from a phone app is dropping more frames after a specific commit? there are things that are hard to test with a script. And usually these are the cases where bisect is very useful, because it reduces two weeks of debugging to two days. Which is still a long time.