"Comment all code and start by uncommenting a line at a time. Iteratively running the code"
I do this even today. Well something like it. I comment out all the code. Run. Uncomment half the code. Run. Figure out which half the funny business is coming from. Cut that in half. Rince and repeat. I call it doing a binary search from bugs. It's a tad faster than a line at a time. It's most useful when you find yourself in long procedural methods. Maybe stop writing those.
Begin to Think that the issue that I am expecting is not the problem. Something else is!
When debugging always be willing to learn something. I catch myself wasting time insisting the universe work the way I think it should.
It's time to talk to someone.
Sometimes it's just time to talk. Start with a rubber duck. They're good listeners.
It's probably a data issue.
I never trust anything works until I have a way to visualize data. Why do you think everyone is so obsessed with seeing "hello world"?
Of recent my experience has been when I started integration testing as a part of a new development. The test fixture setup was the thing taking most time than actual test case or the development itself. It was like I spent more than 2 days fighting with test setup for a single test class.
Would really help to know how can I reduce the stress involved in such situations. Or have you faced such situations? Or any other thoughts from the Masters ? Does facing this issue frequently suggest inefficiency ?
Integration testing should be automated. Period.
This is sadly rarely followed. Because of that it is hands down the most miserable experience I've had in all of IT (not even simply development).
Integration tests need automated repeatability. Achieving this can test you since at times your programming langauge itself can't perform this. You may need to actually learn how to throw your weight around in your operating system.
I actually learned how to write iDSL's because I was sick of manual integration testing. I wrote a mini language that let me set up everything I needed to run my code exactly as it would be in production. By the time I was done I could easily drop my new stuff into a few expressions that brought the system to life. Sure I could have followed the script, I could have just done it by hand. But dammit I'm a programmer not an operator. I did this to a system that wasn't even designed for this kind of testing.
Truthfully what I had was an end-to-end test. This didn't touch the gui and it was happening on my development environment. But so many configuration bugs were happening because the manual testing was a nightmare I just had to do it. Setting it up took time. But man did it pay off.
Now you can get third party tools that brag they can do this crap for you but no one knows your system better than you do. If you're thinking there has to be a better way, there is. You just have to care enough to do it.