Exercising all the paths

Another effective way of utilizing the debugger is to step through all new or modified code to exercise all the data paths contained within one or more procedures. You can do this quickly, often in a single test run. Every program has code that gets executed only once in a very light blue moon, usually code that handles special conditions or errors. Being able to reset the debugger to a particular source statement, change some data to force the traversal of another path, and then continue program execution from that point gives you a great deal of testing power.

 ' This code will work fine - until sTest is empty.
If Len(sTest) > 0 And Left$(sTest, 1) = "0" Then
    DoSomething
Else
    DoSomethingElse
End If

When I first stepped through this code while testing another programmer’s work, the sTest string was 2 bytes long. I stepped through to the End If statement—everything looked fine. Then I used the Locals window to edit the sTest variable and change it to a null string, set the debugger to execute the first line again,…and of course the program crashed. (Visual Basic doesn’t short-circuit this sort of expression evaluation. No matter what the length of sTest, the second expression on the line will always be evaluated.) This ability to change data values and thereby follow all the code paths through a procedure is invaluable in detecting bugs that might otherwise take a long time to appear.