testing and debugging furthermoreeven path-complete test suite does not guarantee that all bugs will be exposed considerdef abs( )"""assumes is an int returns if >= and - otherwise""if - return - elsereturn the specification suggests that there are two possible casesx is either negative or it isn' this suggests that the set of inputs { - is sufficient to explore all paths in the specification this test suite has the additional nice property of forcing the program through all of its pathsso it looks like complete glass-box suite as well the only problem is that this test suite will not expose the fact that abs(- )will return - despite the limitations of glass-box testingthere are few rules of thumb that are usually worth followingexercise both branches of all if statements make sure that each except clause (see is executed for each for loophave test cases in which the loop is not entered ( if the loop is iterating over the elements of listmake sure that it is tested on the empty list) the body of the loop is executed exactly onceand the body of the loop is executed more than once for each while loopo look at the same kinds of cases as when dealing with for loopsand include test cases corresponding to all possible ways of exiting the loop for examplefor loop starting with while len( and not [ = find cases where the loop exits because len(lis greater than zero and cases where it exits because [ = for recursive functionsinclude test cases that cause the function to return with no recursive callsexactly one recursive calland more than one recursive call conducting tests testing is often thought of as occurring in two phases one should always start with unit testing during this phase testers construct and run tests designed to ascertain whether individual units of code ( functionswork properly this is followed by integration testingwhich is designed to ascertain whether the program as whole behaves as intended in practicetesters cycle through