On this post we are going to have a quick look at breakpoints and watches, features we can use during debug to locate code errors.
Breakpoints
You can attach a breakpoint to a line of code to stop script execution at that point. When you go to Run > Run, the application will stop at the first breakpoint, if you go to Run > Run again, it will jump to the second breakpoint, and so on.
With breakpoints, you can take execution flow control through the key parts of your application, those that are relevant to the error you are trying to fix, avoiding unnecessary steps in the middle.
Imagine you have a PHP script with 10,000 lines of code (it happens…), and need to check only when the execution flow goes through two functions, called from different places, at different times. If you have to manage that with basic flow control, you can go crazy. Using two breakpoints instead that would be a piece of cake.
Conditions
But breakpoints are more flexible than that.
You can, for example, define a PHP expression to be evaluated when the execution flow reaches a breakpoint, and the execution flow will then only be stopped if that expression evaluates to true.
For example, if at some point in a long code a variable has an unexpected value, and you know what the correct value would be, you could use a expression like:
$variable !== $expectedValue
That way, the breakpoint would only stop the execution when an unexpected value has been assigned to the variable.
If you just know that at some point in a loop something unexpected happens, you can set a pass count to a breakpoint, so that breakpoint is ignored a certain amount of times before it stops the execution. For example, you could skip the 30 first loops and take on execution control from there.
Watches
The Debugger has views for both local and global variables, but searching for the desired variables on a big project can be a real pain. Watches let you manage list of variables you need to look at during execution flow control.
Also, you can take advantage of groups to associate variables you want to watch, and have them together on different tabs on the Watch List.
That way, if you are jumping between different parts of an application, and there are certain variables you want to watch on each part, you can add those of each part to a group, and just switch between tabs.
After Debugging
We have already seen how to avoid simple errors, and how to use execution flow control and data watching to locate the source of an error. What happens when you locate all errors? Well, then there is always room for improvement.
Next blog post will focus on how to perform one of the most important tasks during the testing of an application: analyzing its performance. We will locate bottlenecks, parts of the code that, while doing their job, are taking a lot of time to do it, or at least more time than they should.
轉至：http://www.dfwlt.com/forum.php?mod=viewthread&tid=341
相關鏈接