testing and debugging after you run the experimentyou are more likely to fall prey to wishful thinking finallyit' important to keep record of what experiments you have tried when you've spent many hours changing your code trying to track down an elusive bugit' easy to forget what you have already tried if you aren' carefulit is easy to waste way too many hours trying the same experiment (or more likely an experiment that looks different but will give you the same informationover and over again rememberas many have said"insanity is doing the same thingover and over againbut expecting different results " designing the experiment think of debugging as search processand each experiment as an attempt to reduce the size of the search space one way to reduce the size of the search space is to design an experiment that can be used to decide whether specific region of code is responsible for problem uncovered during integration testing another way to reduce the search space is to reduce the amount of test data needed to provoke manifestation of bug let' look at contrived example to see how one might go about debugging it imagine that you wrote the palindrome checking code in figure and that you are so confident of your programming skills that you put it up on the web-without testing it suppose further that you receive an email saying" tested your !!**program on the following -string inputand it printed yes yet any fool can see that it is not palindrome fix it!def ispal( )"""assumes is list returns true if the list is palindromefalse otherwise""temp temp reverse if temp =xreturn true elsereturn false def silly( )"""assumes is an int gets inputs from user prints 'yesif the sequence of inputs forms palindrome'nootherwise""for in range( )result [elem raw_input('enter element'result append(elemif ispal(result)print 'yeselseprint 'nofigure program with bugs this line appears in rita mae brown'ssudden death howeverit has been variously attributed to many other sources--including albert einstein