CREATING WEB-BASED TESTWARE in Font

Encoder PDF-417 2d barcode in Font CREATING WEB-BASED TESTWARE

component for this sole purpose. When you want to verify that your code reached a particular line, you set the value of this variable to indicate this event, as shown in Listing 9-20. Listing 9-20. A Simple Way to Add a Print Message in a .dll Public Class Class1 Public strDebugMessage Public Sub DoStuff() strDebugMessage = "Made it to this line" End Sub End Class To verify that the line was processed, you display the value of the variable with a Response.Write() statement like the one in Listing 9-21. Listing 9-21. Displaying the .dll Print Message with an ASP.NET Page Dim c1 As New ClassLibrary1.Class1() Response.Write(c1.strDebugMessage) Of course, this assumes that you have access to the code in the component .dll and can remove these messages once you have completed your debugging. While this would be true when you are writing your own custom piece of testware, if you are just testing someone else s component, then you are left looking at a Black Box. If the developers did not document that there are hidden variables, sometimes called trace flags, you have no way to probe the component in this manner. To make accessing these types of messages more consistent, most languages have added some type of print command that can be turned on and off from outside of the .dll. As we discussed in 4, .NET includes the Debug and Trace statements for this purpose. As you can imagine, database servers have their own ways to print out messages. In fact, the SQL command for this is easy to remember since it is actually called Print. Just as in the other technologies, you add the Print command to verify that a particular line was reached or that a particular value was set. SQL Print statements are often used to test stored procedures. Stored procedures are like methods in that they allow you to store a set of one or more SQL commands on the database server. Just like methods in a Windows or web application, the store procedure is called when you want to run the code inside of it. Of course, it is necessary to debug and test these just like any other method since they contain processing and validation statements. Listing 9-22 is a very simple example that gives you an idea of what this would look like.

Listing 9-22. Printing from a SQL Stored Procedure Create Proc DoSQLStuff As Begin Print 'Got to this line' End To forward this print message from the database, you must pass it through all of the layers up to the browser. Microsoft s ADO.NET will help you capture SQL Print messages and then you can pass them on to the web browser by using the Response.Write() method yet again. Although ADO.NET's SqlConnection.InfoMessage event can be used to do this, it is not exactly simple, and would take us too far off topic.

By now you re probably convinced that multitiered web applications are just harder to test and develop. Perhaps it is easy to understand why developers sometimes skip over some of the debugging chores they should do and pass them along to the testing team. Although the debugging tools in a Windows application are usually easy to use, they can be very complex in a web application. One big problem is that developers need different debuggers for the web browser, the web server, the components, and the database. Microsoft has integrated these different debuggers within Visual Studio, but they don t always work well together, nor are they intuitive to set up. This will likely change one day, but until then, using print statements for troubleshooting and debugging are common tasks even today.