|
|
|
Testing and debugging are often the most difficult and time-consuming phase of program development. VS eases the burden by including an integrated debugger. HOW TO TEST AN ASP.NET APPLICATION You typically test an ASP.NET application by running it from inside of VS.NET. Once you're done testing your app from within VS.NET, you should test it by typing in the URL in different browsers' address window. VS uses Internet Explorer as its default browser. You can view load any page in a browser by right clicking on the page and selecting "view in browser." Before you can run an application with debugging on a remote server, a program called the Remote Debug Monitor must be installed and running on the server. Even before you start testing it from outside of VS.NET, you can choose different browsers from within VS.NET by selecting File-->Browse With from the menu bar. Then choose the browser from the dialog box. If the browser is installed on the local machine, but isn't available from the dialog box, click the add button to include it. However, debugging will not be available with the new browser unless you set the new browser to be the default browser by clicking the "set as default" button. This will also cause VS.NET to load your application in the new browser until you reset your old browser as the default.
VS.NET provides you with an internal browser, but you can't debug while using it. Therefore it's not very handy. If you choose debug-->start without debugging, then you won't enter break mode when an exception occurs. TESTING A FILE SYSTEM WEB SITE One major issue with testing a file system site is that it always runs on the current user's security context. Since the site designer likely has more rights than an average user, security issues may arise when the application gets moved to the production server. Furthermore, the ASP.NET development server can only serve pages to the local computer, doesn't include an SMTP server so Email applications can't be tested, and uses a random port instead of the standard Web port, port 80. You can test a file system Web site using IIS if you create a virtual directory and then use the file system's property pages dialog box to specify the URL for the virtual directory. You right click on the project name to access the property pages.
You can also enter the URL for an application's start page into the browser's address window. However, you'll have to compile the applicaiton before it's available. If it's an IIS site, you use LOCALHOST as your domain name without specifying a port number. Here's a video on how to set up a virtual directory in IIS. HOW TO USE THE DEBUGGER If an uncaught exception occurs in an ASP.NET application, ASP.NET terminates the application and sends the error page to the browser:
Just like with Windows applications, you start by setting a breakpoint. Breakpoints remain even after you close the project. You can remove breakpoints by clicking on the breakpoint in the code window or by deselecting the check box from the breakpoints window. If you want to clear all breakpoints in one shot, choose debug-->clear all breakpoints from the menu bar. You can only set breakpoints for lines that contain executable code. For example, you can't set a breakpoint on a line that declares a variable. Once your application is running and you hit a breakpoint, your application moves from run mode to break mode. The breakpoint that caused your application to enter break mode is highlighted.
At this point you can take advantage of the variety of different debugging windows/techniques offered by VS.NET. When you are in break mode, you can run your cursor over any variable to see its current value. When you enter break mode, the toolbar contains a continue button. You click this button to move from break mode back to run mode. Execution continues on the line where the break occurred.
When a procedure is called, the lines of the procedure can be executed one at a time. This is called stepping into a procedure. You can press F11 or the button pictured below on the debug toolbar.
Stepping into a procedure allows you to micromanage your application, as you step through your code line by line. When a procedure is called, the procedure can be executed all at once instead of one line at a time. This is known as stepping over a procedure. Click the button pictured below on the debug toolbar. You will still be in break mode after the procedure is stepped over.
If you're inside a procedure, and want it to finish executing, you should step out of the procedure. Click the button pictured below on the debug toolbar to step out of a procedure. You will still be in break mode after the procedure is finished executing.
You can skip over code that you know is working by using the Run to Cursor option. Just right click on the line of code you'd like to skip to and select "run to cursor." This will cause execution to continue, but halt again once that line of code is reached.
THE IMMEDIATE WINDOW
You use the immediate window to find out variable's current values or to set variable values. If you type "?x" in the immediate window and press the enter key, the next line will display the current value of x. If you type "x = 5" in the immediate window and press the enter key, x will be assigned the value of five. Of course, x will only have the value of five THIS time the page is loading or until x is assigned another value elsewhere in the code. Trying to execute either of the above statements while the program is in run mode will cause the following message to appear in the immediate window:
THE WATCH WINDOW
To delete an expression from the watch window, right click on the expression and then click "Delete Watch". You can directly alter the value of any variable from the Watch window and have the values of the other expressions change as well. Simply click in the value column and change the variable's value. When you go back into run mode, the program will continue as if the execution of the program was responsible for changing the value. THE LOCALS WINDOW
The locals window automatically displays the names, values, and types of all variables in the current procedure. You can click the plus signs to view more information about each object listed in the locals window. THE AUTOS WINDOW This window is similar to the Locals window, except that it only displays information about the variables, properties and constants used in the current statement as well as the three before and after the statement. This keeps the focus on the variables that have most recently been utilized or will be utilized shortly thereafter. EDIT AND CONTINUE VS.NET 2005 includes a feature called Edit and Continue that lets you change almost any executable statement while in break mode. You just make the change in the code editor and then continue program execution. However, you're not allowed to change declaration statements. You can't add, change or remove an Imports statement and you can't change the access modifier for a property or method. If you make a code change that isn't allowed, VS.NET marks the change with a purple wavy underline and adds an error to the error list. TRACEPOINTS A tracepoint is a special type of breakpoint that performs an action when it's encountered. To activate a tracepoint, you use the "When Breakpoint is hit" dialog box. You access this by right clicking on the statement that should have the tracepoint. You'll usually use the "print a message" option to display a message in the immediate window. The message can include variable values and other expressions as well as special keywords. To open the immediate window in break mode, choose debug-->windows-->immediate By default, program execution continues after the tracepoint action is performed. You can remove the continue execution checkmark if you wish. If program execution is scheduled to continue, the tracepoint indicator will appear as a large diamond. Otherwise it will be marked just like any other breakpoint. You can also convert a traditional breakpoint to hit point by right clicking on the indicator and choosing "when hit" This feature is not available in the Visual Web Developer Express Edition. COMMON ERRORS There are many situations where an error will occur in your application. When an error occurs, ASP.NET checks to see if there are any active error handlers in the procedure where the error was thrown. If not, ASP.NET checks to see if there are error handlers in the calling procedure. After working its way up the food chain without finding any error handlers, ASP.NET finally crashes and an error page is displayed in the browser. The error page indicates the type of exception that occurred and the statement that caused the error. It also includes the line number as well as a stack trace indicating what processing occurred right before the exception was thrown. This will usually, but not always give you enough information to discover why the error occurred. When there's not enough information available, you can set breakpoints in the debugger. Carefully designed pages will almost never display an error page. That's because the programmer anticipated the possibility of error and incorporated a means of handling/catching the errors, identifying them, and continuing the application without crashing. The Microsoft .NET Framework uses exceptions to catch errors. This is different than the error codes that were used in VB6. Exceptions occur when something out of the ordinary happens while an application is running. Exceptions can provide information about what caused the error and where it occurred. There are a number of benefits to using exception handling:
|
