In today's contest, I got a WA in problem 3. So I thought of doing a stress testing of my solution, but my workflow was so slow that it took me around 1 hour to debug my code. Is there anything I should improve so that I can do such debugging fastly in contests? I am describing the steps I did: I wrote a brute force solution. I wrote code for randomly generating the test cases. I then ran both the solutions I had against the generated test-cases. I then used https://www.diffchecker.com/ to find the difference between both the outputs. I then opened the randomly generated tests file (which had 300+ test cases) and then navigated to the test case for which the output was different. Then I ran that particular test case separately and did the debugging.
"I then used https://www.diffchecker.com/ to find the difference between both the outputs. I then opened the randomly generated tests file (which had 300+ test cases) and then navigated to the test case for which the output was different." This part can be automated.
Some tips:
Consider finding a minimal test case where the bug can be reproduced. When you find a test that has 300 lines, usually you can find a smaller test with the same bug. This can be done by rerunning the generator with smaller parameters or by manually pruning the test case.
Instead of writing separate brute solution and generator you can implement everything on the same file, two solutions (reusing functions you are confident about), test generation and asserts about expected outcome... Also
This video could be helpful for you to automate some of the steps you have done, thus reducing the debugging time during the contest.
At least you got it debugged :(
Sounds like you jumped to doing stress testing way to soon. In my experience manually testing a bunch of small test cases usually works.