Testing the Web Service

In addition to the Add method shown in Listing 15-7 and the LogMessage function shown in Listing 15-9, the Events web service contains three other public web methods called Delete, Open, and HelloWorld. Delete and Open are similar to the Add function in that they perform some data read or write function based on end-user submitted data. HelloWorld is the default method that Visual Studio .NET Component Designer places in all new web services to demonstrate how to make a method in the web service available to web access.

If the ASMX for the web service is set as the startup file, the web service can be run and debugged in Visual Studio .NET. Press F5 to start the compiler; if no errors are found, the web browser will open with a default web service test harness provided by the .NET Framework, as shown in Figure 15-17.

Figure 15-17: Requesting a web service using a web browser

Click any of the method calls to open a new page that displays a data entry form based on the parameters of the method. The HTTP and SOAP request and response are defined and described under the data entry fields for the method being described. Data placed in the text boxes presented in the test screen will be passed as arguments for the method’s parameters after you click the Invoke button. Figure 15-18 shows the Open method test screen in the web browser.

Figure 15-18: Open method of the Events web service requested from web browser

Set the ID with a value of 13 and click the Invoke button, and another web browser instance will open with the result of the call to the Open method formatted into XML. Because the Open method returns true or false depending on the success or failure of the function to execute, the response is quite minimal and does not help demonstrate whether the web service really opened the record correctly; however, the feedback does indicate that the web service believes it functioned correctly, since it returned a value of true, as shown in Figure 15-19. It would be much more useful to see the data being pulled from the data source, so the default test harness provided by the .NET Framework may not be very suitable for unit testing your web service.

Figure 15-19: Response of Open method in web browser

Writing a Test Harness

The actual value that was opened on the Open method is stored in the Events class property called Event. The intended use of the Events class is for a consumer to call a method such as Open or Add and have a value returned that indicates whether or not the call was successful. If the call is successful, the Event data could be obtained from the Event property.

The test harness provided by the .NET Framework does not display the values in a web service property, and a property cannot be identified as a web method using the [WebMethod] identifier. The WebMethod identifier is placed above any public method that should be exposed as an XML web service. In this case, a test harness should be written to use the web service and display the results so that it can be verified that the code functioned properly.

Web forms are great mechanisms for producing a web service test harness. For the Events class Add method, a web form that adds an event was produced called EventClient .aspx. Web forms offer a calendar control to the developer that is ideal for capturing the date from the end user. Two text boxes for the name and description of the event may be pasted on a web form, along with the calendar control. To show the resulting ID of the new event after the Add function is successfully executed, a text box that displays the ID and the Submit button is added so that the web form will know when to respond to the end user. Figure 15-20 shows a calendar control Add method after an event was added.

Figure 15-20: Add method web form test harness

The code behind the web form EventClient.aspx, shown in Listing 15-10, is simple. As shown in Figure 15-20, a control on the form exists for each property of the class anEvent. The Submit button is used to trigger the event of calling the Add event. The code behind the EventClient.aspx web form consists mostly of the button click event function for the btnAdd control. The web form EventClient.aspx should be run in the same web application that hosts the web service. The sole purpose of the web form EventClient.aspx is to unit test the code and make certain that the functions in the web service Events work properly, so it was kept as simple as possible and provides the developer useful feedback about the performance of Events web service.

Listing 15-10: Source Code for Events Add Function Test Harness - Web Form EventClient.aspx

 /// <summary> /// Summary description for EventClient. /// </summary> public class EventClient : System.Web.UI.Page {      protected System.Web.UI.WebControls.Calendar Calendar1;      protected System.Web.UI.WebControls.TextBox txtName;      protected System.Web.UI.WebControls.Label Label1;      protected System.Web.UI.WebControls.Label Label2;      protected System.Web.UI.WebControls.TextBox txtDescription;      protected System.Web.UI.WebControls.Label lblFeedback;      protected System.Web.UI.WebControls.Button btnAdd;      private void Page_Load(object sender, System.EventArgs e)      {           //don't show the feedback text box until           //there is a good reason           this.lblFeedback.Visible = false;           //make the numbers red that are selected in calendar           this.Calendar1.SelectedDayStyle.ForeColor =                System.Drawing.Color.Red;      }      #region Web Form Designer generated code      override protected void OnInit(EventArgs e)      {      //      // CODEGEN: This call is required by the       // ASP.NET Web Form Designer.      //        InitializeComponent();           base.OnInit(e);      }            /// <summary>      /// Required method for Designer support - do not modify      /// the contents of this method with the code editor.      /// </summary>      private void InitializeComponent()  {       this.btnAdd.Click += new System.EventHandler(this.btnAdd_Click);    this.Load += new System.EventHandler(this.Page_Load);  }      #endregion      private void btnAdd_Click(object sender, System.EventArgs e)      {           Events myEvents = new Events();           anEvent myEvent = new anEvent();           //get the name           myEvent.Name = this.txtName.Text;           //get the date/time           myEvent.DateTime = this.Calendar1.                SelectedDate.Date;           //get the description           myEvent.Description = this.txtDescription.Text;                      myEvents.Event = myEvent;           //add it           if (myEvents.Add())           {                this.lblFeedback.Visible = true;                lblFeedback.Text = "Wrote a new date with ID = " +                     myEvent.ID;                           }           else           {                this.lblFeedback.Visible = true;                lblFeedback.Text = "Unable to write date";           }      } }

The Visual Studio .NET Component Designer added the Click event automatically when the control btnAdd was double-clicked in design view. A class instance for anEvent and the Events web service are created in the beginning of the Click event. Since these classes all exist in the same namespace, there is no need to refer to the namespace or place a using directive at the top of the source code for the namespace myPortal. The event being added is represented by an instance of anEvent named myEvent. The Events instance is named myEvents. The properties for myEvent are obtained from the calendar txtDescription and txtName controls. When myEvent is filled with the end-user submitted data, it is placed in the event property of the instance myEvents. The myEvents Add function is called, and if successful, the success message is written to the lblFeedback control; otherwise, a failure message is written to the lblFeedback control.

It should also be pointed out that no error handling exists in this code. Because this code is designed to test for failure and not serve in a production capacity, it is better not to have error handling. The test harness is for the developer to analyze failure. Allowing unhandled errors to occur will provide better data for developers to help them understand the robustness of features of the code.

The test harness should be kept and stored in the same way that other source code for the web service is stored. The harness will help to provide a future means of reference showing how the solution works, and it may be used to test future enhancements to the web service.