Testing a Windows Forms Application

How to test a project

When you test a project, you run it and make sure the application works correctly. As you test your project, you should try every possible combination of input data and user actions to be certain that the project works correctly in every case. In other words, your goal is to make the project fail. Figure 3-17 provides an overview of the testing process for Visual Basic applications.

To start, you should test the user interface. Make sure that each control is sized and positioned properly, that there are no spelling errors in any of the controls or in the form’s title bar, and that the navigation features such as the tab order and access keys work properly.

Next, subject your application to a carefully thought-out sequence of valid test data. Make sure you test every combination of data that the project will handle. If, for example, the project calculates the discount at different values based on the value of the subtotal, use subtotals that fall within each range.

Finally, test the program to make sure that it properly handles invalid data entered by users. For example, type text information into text boxes that expect numeric data. Leave fields blank. Use negative numbers where they shouldn’t be allowed. Remember that the goal of testing is to find all of the problems.

As you test your projects, you’ll encounter runtime errors. These errors, also known as exceptions, occur when Visual Basic encounters a problem that prevents a statement from being executed. If, for example, a user enters “ABC” into the Subtotal text box on the Invoice Total form, a runtime error will occur when the program tries to assign that value to a decimal variable.

When a runtime error occurs, Visual Studio breaks into the debugger and displays an Exception Assistant window like the one in this figure. Then, you can use the debugging tools that you’ll be introduced to in the next figure to debug the error.

Runtime errors, though, should only occur when you’re testing a program. Before an application is put into production, it should be coded and tested so all runtime errors are caught by the application and appropriate messages are displayed to the user. You’ll learn how to do that in chapter 7 of this book.

The Exception Assistant that’s displayed when a runtime error occurs

How to test a project

1. Test the user interface. Visually check all the controls to make sure they are displayed properly with the correct text. Use the Tab key to make sure the tab order is set correctly, verify that the access keys work right, and make sure that the Enter and Esc keys work properly.
   
2. Test valid input data. For example, enter data that you would expect a user to enter. 
    
3. Test invalid data or unexpected user actions. For example, leave required fields blank, enter text data into numeric input fields, and use negative numbers where they are not appropriate. Try everything you can think of to make the application fail.

Description

1. To test a project, you run the project to make sure it works properly no matter what combinations of valid or invalid data you enter or what sequence of controls you use.
   
2. If a statement in your application can’t be executed, a runtime error, or exception, occurs. Then, if the exception isn’t handled by your application, the statement that caused the exception is highlighted and an Exception Assistant window like the one above is displayed. At that point, you need to debug the application.

Figure 3-17.   How to test a project

How to debug runtime errors

When a runtime error occurs, Visual Studio enters break mode. In that mode, Visual Studio displays the Code Editor and highlights the statement that couldn’t be executed, displays the Debug toolbar, and displays an Exception Assistant dialog box like the one shown in figure 3-17. This is designed to help you find the cause of the exception (the bug), and to debug the application by preventing the exception from occurring again or by handling the exception.

Often, you can figure out what caused the problem just by knowing what statement couldn’t be executed, by reading the message displayed by the Exception Assistant, or by reading the troubleshooting tips displayed by the Exception Assistant. But sometimes, it helps to find out what the current values in some of the variables or properties in the program are.

To do that, you can place the mouse pointer over a variable or property in the code so a data tip is displayed as shown in figure 3-18. This tip displays the current value of the variable or property. You can do this with the Exception Assistant still open, or you can click on its Close button to close it. Either way, the application is still in break mode. In this figure, the data tip for the Text property of the txtSubtotal control is “$$1000”, which shows that the user didn’t enter valid numeric data.

Within the data tip, you’ll see a magnifying glass and an arrow for a drop-down list. If you click on this arrow, you’ll see the three choices shown in this figure. Then, if you click on Text Visualizer, the value in the data tip will be shown in the Text Visualizer dialog box the way it actually is. So in this simple example, the value will show as $$1000, not “$$1000”. Although that isn’t much different than what the data tip shows, the differences are more dramatic when the data is more complex.

Once you find the cause of a bug, you can correct it. Sometimes, you can do that in break mode and continue running the application. Often, though, you’ll exit from break mode before fixing the code. To exit, you can click the Stop Debugging button in the Standard toolbar. Then, you can correct the code and test the application again.

For now, don’t worry if you don’t know how to correct the problem in this example. Instead, you can assume that the user will enter valid data. In chapter 7, though, you’ll learn how to catch exceptions and validate all user entries for an application because that’s what a professional application has to do. And in chapter 12, after you’ve learned the Visual Basic essentials, you’ll learn a lot more about debugging.

How a project looks in break mode

Description

1. When an application encounters a runtime error, you need to fix the error. This is commonly referred to as debugging, and the error is commonly referred to as a bug.
   
2. When an application encounters a runtime error, it enters break mode. In break mode, the Debug toolbar is displayed along with the Exception Assistant window. 
    
3. The information in the Exception Assistant window should give you an idea of what the error might be. You can also click on the links in the Troubleshooting Tips list to display more information in a Help window. 
    
4. If you close the Exception Assistant window, the application remains in break mode. 
    
5. To display a data tip for a property or variable, move the mouse pointer over it in the Visual Basic code. 
    
6. If the data tip includes a drop-down arrow to the right of a magnifying glass, you can click the error and select Text Visualizer to see exactly what the data looks like. 
    
7. To exit break mode and end the application, click the Stop Debugging button in the Standard toolbar or press Shift+F5. 
    
8. You’ll learn more about debugging and the Exception Assistant window in chapter 12.

Figure 3-18.   How to debug runtime errors

Perspective

If you can code and test the Invoice Total project that’s presented in this chapter, you’ve already learned a lot about Visual Basic programming. You know how to enter the code for the event handlers that make the user interface work the way you want it to. You know how to build and test a project. And you know some simple debugging techniques.

On the other hand, you’ve still got a lot to learn. In particular, you haven’t learned much about the Visual Basic language. That’s why the next six chapters present the Visual Basic essentials.

Terms

Exercise 3-1   Code the Invoice Total form

In this exercise, you’ll add code to the Invoice Total form that you designed in exercise 2-1. Then, you’ll build and test the project to be sure it works. You’ll also experiment with debugging and review some help information.

Copy and open the Invoice Total application

1. Use the Windows Explorer to copy the Invoice Total project that you created for chapter 2 from the C:\VB 2008\Chapter 02 directory to the C:\VB 2008\Chapter 03 directory.
   
2. Open the Invoice Total solution (InvoiceTotal.sln) that’s now in the C:\VB 2008\Chapter 03\InvoiceTotal directory.
   
   Add code to the form and correct syntax errors
   
3. Display the Invoice Total form in the Form Designer, and double-click on the Calculate button to open the Code Editor and generate the procedure declaration for the Click event of this object. Then, enter the code for this procedure as shown in figure 3-6. As you enter the code, be sure to take advantage of all of the Visual Studio features for coding including snippets.
   
4. Return to the Form Designer, and double-click the Exit button to generate the procedure declaration for the Click event of this object. Enter the statement shown in figure 3-6 for this event handler.
   
5. Open the Error List window as described in figure 3-9. If any syntax errors are listed in this window, double-click on each error to move to the error in the Code Editor. If the Auto Correction feature is available for an error, check to see whether its suggested correction (or one of its suggested corrections) is the one you want to make. Then, correct the error.  
   
   Test the application
   
6. Press F5 to build and run the project. If any syntax errors are detected, you’ll need to correct the errors and press F5 again.
   
7. When the application runs and the Invoice Total form is displayed, enter a valid numeric value in the first text box and click the Calculate button or press the Enter key to activate this button. Assuming that the calculation works, click the Exit button or press the Esc key to end the application. If either of these procedures doesn’t work right, of course, you need to debug the problems and test the application again.  
   
   Enter invalid data and display data tips in break mode
   
8. Start the application again. This time, enter xx for the subtotal. Then, click the Calculate button. This will cause Visual Studio to enter break mode and display the Exception Assistant.
   
9. Note the highlighted statement and read the message that’s displayed in the Exception Assistant. Then, close the Assistant, and move the mouse pointer over the property in this statement to display its data tip. This shows that the code for this application needs to be enhanced so it checks for invalid data.  
   
10. Display the smart tag for the Text property in the highlighted statement, click its drop-down arrow, and select Text Visualizer. This shows the data exactly as it was entered in the Text Visualizer dialog box. Then, click the Stop Debugging button in Standard toolbar to end the application.  
    
    Experiment with the Visual Basic features
    
11. In the Dim statement for the discountPercent variable, change the variable name to discountPct. When you do that, a bar will appear under the last letter of the variable. Place the mouse pointer over this bar to display a drop-down arrow. Then, click on this arrow and select the Rename command. This should rename the discountPercent variable to discountPct throughout the form. But run the form to make sure it’s working correctly.
    
12. In the If statement, right-click on one of the occurrences of the variable named discountPct. Then, select the Rename command, and use it to rename this variable to discountPercent throughout the form. To make sure this worked, run the application.
    
13. Select the lines that contain the ElseIf clauses and click on the Comment Out button in the Standard toolbar. That should change these coding lines to comments. Then, run the application to see how it works when these lines are ignored. When you’re done, select the lines that were commented out and click on the Uncomment button to restore them.  
    
14. In the Code Editor, click on the minus sign in front of the btnCalculate_Click procedure to collapse it. Then, expand that procedure and collapse the btnExit_Click procedure. Last, print just the expanded code for this form.  
    
15. In the Solution Explorer, show all the files and double-click on the file named frmInvoiceTotal.Designer.vb to open it in the Code Editor. This is the code that determines how the form will look when it’s instantiated. After you read chapter 11 and section 4, this code will make more sense to you. For now, though, just close the window with this code.  
    
    Experiment with the Help feature
    
16. To see how context-sensitive help works, place the insertion point in the Select method in the last statement of the first event handler and press F1. This should open a Help window that tells you more about this method. 
     
17. In the left pane, select the Index tab to display the Index window. Type “snippets” into the Look For box to see the entries that are listed under this topic. Next, if Visual Basic (or Visual Basic Express Edition) isn’t selected in the Filtered By drop-down list, select it to show just the topics for Visual Basic. Then, click on one or more topics to display them. 
     
18. Use the Tools->Options command, and review the help options. In the Online group, you may want to change the loading option to “Try local only, not online,” because that can speed up the access of help topics.  
    
19. Continue to experiment with the Index, Contents, Help Favorites, and Search features to see how they work, and try to use some of the buttons in the Standard toolbar to see how they work. Then, close the Help window.  
    
    Exit from Visual Studio 
    
20. Click the Close button for the Visual Studio window to exit from this application. If you did everything and got your application to work right, you’ve come a long way!