3 ms·
You can also avoid getting frustrated by using a more test driven development. Incrementally write code, then test (could be just printf-ing), then chances are
by lalos 14y ago
You can also avoid getting frustrated by using a more test driven development. Incrementally write code, then test (could be just printf-ing), then chances are that the bug is in the last chunk of code written.
- greenyoda 14y agoTesting your code as you develop is very useful, but it isn't a panacea for avoiding all bugs. Lots of times, bugs show up because of something you didn't realize could go wrong. And if you didn't realize it could go wrong, you also didn't realize that you should write a test for it. If it's a rarely occurring problem, it might first be reported by a customer a couple of years later, so you can only narrow it down to something that's changed in the last few years.
- sax 14y agoI am working on a project that aims to standardize the use of bisection to narrow-down and arrive at root-cause of bugs. One approach is to run regex on your output logs to determine what modules are running into issues. check out http://bisect.cc http://bisect.cc
- banachtarski 14y agowhat are the differences between a vanilla `git bisect`
- ollysb 14y agoTDD can be a great way to debug, particularly if it takes a lot of effort to get your running app into the state where the bug occurs. Write a cucumber scenario that sets up the conditions where you think the bug occurs and tweak until you're able to replicate. If you know when a bug occurred you can take a look at your logs and then use those to construct your bug scenario in cucumber. Once you're able to replicate in cucumber it's usually far faster to fix because your test cycles are much shorter (automatic vs having to put the running app in the correct state each time).