poikniok's blog

Test Driven Approach to Solving Contest Problems
By poikniok, 9 years ago, In English

So recently I have been trying a new approach to solving problems, which is whenever possible to implementing a quick brute force solution to a problem and then generating testcases with random numbers, and using the brute force solution to generate the answer to these testcases. While of course I can only generate tests with fairly small constraints typically relative to the actual input size, I have found that this approach catches a lot of bugs that I otherwise miss. I came up with this idea from watching Petr and Egor’s screencasts, as it seems they occasionally code up brute force solutions to test against when their submission fails pretests. Now of course I think there are some situations where there is no simple brute force algorithm, and therefore this is not possible. However I am curious if anybody else follows a similar approach during contests themselves, as I am curious if this is a scalable approach as one becomes better. Because while I am not particularly good right now this approach I think saves me more time hunting for bugs on average than it takes in creating the brute force solution. Anyway interested in any feedback, whether people think this is silly or otherwise.

  • Vote: I like it
  • +35
  • Vote: I do not like it

»
9 years ago, # |
← Rev. 2   Vote: I like it +4 Vote: I do not like it

I generally use the above approach in case of long contests, where the time is more. But in case of short contests, if my code got wrong answer, then I try to think or check with boundary cases, overflow cases, some random tests using pen and paper. But the foremost thing I do is "I read the question again to find out whether I missed something."

→ Reply
»
9 years ago, # |
← Rev. 2   Vote: I like it 0 Vote: I do not like it

I use this method a lot, especially in long contests where time is not a concern. In short contests, this doesn't help much as the time it takes to write a brute forcer and a brute force solution takes lot of time which could have been used to debug the code by hand.

→ Reply