Functional Testing of ASP.NET Web Pages With TestComplete

Author: AutomatedQA
Last Updated: June 22, 2009
Applies to: TestComplete 7

QA testing is an important part of web application design. Functional testing allows checking how an object works, in our case it allows determining whether fa web page is properly functioning. You can effectively organize the testing process by using special automated testing environments. TestComplete, an automated testing tool, supports testing any web controls, from simple HTML inputs, up to complex navigation, grid controls placed on a web page. Often grid controls represent data from a database on company’s web pages. Therefore it is very important to have useful methods for functional testing these controls. With TestComplete, you can easily create such methods, write tests based on them and then automate testing of whole pages. This testing approach allows saving time and money, especially if you have a lot of web pages with many complex controls on them.

Functional testing of web sites includes testing of each particular page of the site. This article describes how to create tests checking the ASP.NET page functionality and how to automate the QA testing process with TestComplete. We will also give examples of methods performing common tasks in testing grid controls. After inspecting your custom grid, you will be able to create own methods performing similar tasks.

You can download TestComplete project using the links from the box on the right.

Planning ASP.NET Tests

So, we have a tested object, it is an ASP.NET page. According to certain business rules, our page must properly load and correctly represent data from the database. Every control on the page must also behave as the developer intended.

To demonstrate testing ASP.NET page functionality, we will test a page with a grid control placed on it. To do this, we will create a TestComplete project, write all necessary tests and then automate all actions with it.

We will also write a number of procedures which perform common tasks in testing pages: finding the needed cell, getting a value from a grid cell, searching a value by key in the grid, obtaining values from the specified columns and so on. It becomes possible because TestComplete provides specific methods and properties giving access to the controls and other elements of your ASP.NET page. These methods and properties simplify test development process greatly.

We will implement helper procedures as scripting routines. You can modify the code in compliance with your grid’s peculiarities and then use these procedures in QA testing of your particular grid.

So, our testing plan is:

• Determining the tested object (the ASP.NET page)
• Creating the TestComplete project
• Creating Functional Tests
• Automating Functional Tests
• Running Functional Tests and Viewing Results

About Tested Page

In this article, we will create tests for the following ASP.NET page: http://www.automatedqa.com/examples/testcomplete/employees/

We will not consider the page design, because the goal of our article is functional testing, not the design. So, we will work with a ready-made page.

The page represents data about some company’s employees. It retrieves this information from the Northwind.mdb database which is a part of Microsoft Access.

To display data, the page uses the Developer Express ASPxGridView control (we use the trial version of Developer Express controls in demonstration purposes).

Picture 1 – The Tested Page

Of course, you can use any other ASP.NET controls on your pages and test these pages with TestComplete. The common principles of functional testing described in this article are suitable for testing pages with any kind of ASP.NET controls. However, different controls have some peculiarities, so you should inspect your control’s structure before you will write tests for it.

Which Browser to Choose

In general case, to test ASP.NET pages, you can use any web browser. TestComplete can record and simulate user actions on any window existing in the operating system. However, to make the testing really powerful, we’d recommend that you use the browsers which TestComplete supports for web testing:

• Internet Explorer 5 -8 (or any other browser based on the Microsoft WebBrowser control)
• Firefox 1.5 – 3.0

The benefit is that the test engine provides access to elements of web pages that are shown in these browsers, so you can use the elements’ methods and properties in your tests. Also, access to the web page elements makes the tests object-oriented. Without this access, TestComplete will simply emulate coordinate-based mouse clicks.

Creating the TestComplete Project

TestComplete works with automated tests organized into projects. For instance, it is useful to have a particular project for each web site. Each project consists of project items that perform automatic testing operations or assist in performing these operations. So, we will start creating our tests with creating a TestComplete project:

1. Launch TestComplete. Click the Create a New Project item in the Start Page. After the Create New Project dialog appears, type the name of the future project, in our case it will be "ASP.NETPageTesting". Then select the preferred scripting language and specify the project location in the computer.

   
   
   Picture 2 – Creating New Project

   After the settings are ready, you can click the Create button.

   After you click the Create button, a new project suite will be generated and the ASP.NETPageTesting project will be added to it. We will use the following project’s items:

   • TestedApps – here we add the tested applications
   • Script – here we define functional tests and some helper scripting routines
   • KeywordTests – here we automate launching and stopping the browser

Defining Tested Applications

TestComplete projects maintain a list of tested applications to help you manage these applications in convenient manner. We will add a web browser to this list and then use specific commands to quickly launch the browser before running the tests and close it when the testing is over.

To add the browser to the tested applications list:

1. Right-click the TestedApps project item in the Project Explorer panel and select Add| New Item from the context menu. This will invoke the standard Open File dialog.
2. Find the browser’s executable in the dialog. For instance, the Internet Explorer’s executable is IEXPLORE.EXE. For Windows XP or Vista the path to the executable may be the following: "c:\Program Files\Internet Explorer\IEXPLORE.EXE". Click Open.

Now the browser is added to the list. And we can launch with one command. Let’s modify the browser’s command line arguments, so that the browser opens the tested web page at start:

1. Click the ellipses button in the Parameters column. This will invoke the Parameters dialog:

   
   
   Picture 3 – Specifying Command Line Parameters

2. Enter the URL of the tested page into the Command line parameters box.
3. Click OK to save the changes and to close the dialog.

Choose File | Save All from TestComplete’s main menu to save the changes you made to the project.

Creating Functional ASP.NET Tests

What tests we need? On the one hand, tests must check whether the page correctly responds to the user actions. On the other hand, we need universal enough tests that we can also apply for testing other ASP.NET pages. So, we will create the number of tests checking the following:

1. There must be a table with data on the page
2. There must be data for Davolio, Leverling in the table
3. The visitor must be able to select items from the table
4. The visitor must be able to enter the editing mode for the specified row
5. The visitor must be able to calculate ages for selected people
6. The visitor must be able to clear the "Calculated Age" column

We will implement these functional tests as scripting routines. We chose scripting, because it is quite an obvious way of creating short and effective tests. All the more so because TestComplete provides enhanced name mapping that simplifies working with objects and makes the script code easier to understand.

We will also automate launching and stopping the browser by creating two simple keyword tests. Keyword test is another test implementation approach. It does not require any programming experience for creating tests. So, we use both keyword tests and scripting routines to demonstrate basic principles of working with them. You can compare these implementation techniques and choose the most appropriate for your QA testing tasks.

Creating the Script Unit

First of all to start implementing functional tests, we should add a new script unit to the project. To do this, right-click the Script project item and select Add | New Item from the context menu. Specify the unit’s name and location in the Create Project Item dialog. Click OK. We will create the RecordedTests unit to record a simple functional test into it.

Picture 4 – Create Project Item Dialog

Now the RecordedTests unit is ready for adding routines.

Recording a Simple Functional Test

To understand how to write automated tests, we can record some testing actions over the page with TestComplete. Then, after analyzing the recorded test, we will be able to write our functional tests. User actions over the tested object can be recorded as keyword tests, scripting routines and low-level procedures. We will record a scripting routine. Then, after inspecting how the recorded test is organized, we can write our own tests in the similar way.

To record a test:

1. Select Record Script from the TestComplete’s toolbar.
2. After TestComplete have started recording, perform the following sequence of user actions over the page:
   • Select rows with the information about Suyama and Leverling.
   • Click the Calc Ages button.
   • Wait until the page is completely loaded.
   • Click the Clear Ages button.
3. The test is finished. Click the Stop button on the Recording toolbar.

The recorded test will look as follows:

As you can see, TestComplete generates short names, which are called aliases, for objects on which we perform testing actions during recording. Aliases are available via the Aliases object. For instance, this is the short name for IEXPLORE process:

You also can refer to objects by their short names via the NameMapping object. For instance, you can refer to IEXPLORE process as follows:

Now we can also refer to the tested page by its alias:

Referring the object by its short name, we can invoke methods, obtain property values and so on. For instance, to click the Calc Ages button on the tested page we can use the following code:

Where submitbuttonButton1 is the alias for the Calc Ages button.

Using aliases makes scripting routines shorter and more readable. You can also create short names for objects manually, modify automatically generated names and so on. To create an alias for the object, you should specify the property collection which identifies the object in the system. Further we will refer to objects only by their aliases.

Creating Helper Routines

As we will work with the grid control, we will need methods obtaining values from particular cells, methods searching values within the grid and so on. It is useful to implement these actions as additional helper routines in a particular script unit. For this purpose, you can add a new unit to the project and name it, for instance, "WorkingWithGrid". However, before testing we should make sure that the tested page is completely loaded to the browser. This checking we can also implement as a particular helper routine.

First of all we should define the url of our tested web page. To do this, you can open just created WorkingWithGrid unit and define a variable that will contain the page’s URL:

Further we will use this variable in our tests.

Checking the Page Loading

Now we should define a method checking whether the page is loaded to the browser. First of all we should check whether the browser is running. To do this, we will use the Exists method. If the browser is launched, we will call the same method for the page object to determine whether it is loaded to the browser. To obtain the list of processes, we will use the Sys object. Note that we refer to objects by their aliases in the following code:

We use objects’ short names, or in other words, aliases, in the script code above. TestComplete automatically generate them when you are recording tests. You can also create aliases manually using the Object Browser panel or the NameMapping project item.

Determining the Object on the Page

After we make sure that the tested page is loaded, we can obtain the row and column of specified value in the grid view control.

How can we determine the object on the page? TestComplete provides a useful tool for quick finding the needed element – Object Properties Window. Suppose we need to get the name of the object corresponding to the data table in the grid view control.

1. Open the tested page in the browser (we use Internet Explorer).
2. Select the Object Properties… from the Object Browser context menu:

   
   
   Picture 5 – Object Browser Context Menu

After that the Object Properties window will appear. Drag the Finder tool to the desired element and then release the mouse button:

Picture 6 – The Object Properties Window

Now the Object Properties window shows properties of the specified object. To find the object in the Object Browser, click the button. We can also determine other objects in the same way: cells from the grid view, buttons on the page form and so on.

After we have found the object in the Object Browser panel, we can map its name and create an alias for easy addressing the object. To do this, select Map the Object Name from the context menu (Picture 5).

Writing Helper Routines

Now we know how to refer to the objects on the page. Let’s define some helper scripting routines that we will further use in functional tests. These routines will perform working with values in the grid, searching and so on.

However, before we start writing tests, we should have a look on the tested page more intently. The main control on our page is the grid. Generally, we will test the grid functionality, so we should inspect the grid more detailed. What is it’s structure? Our grid is a table of cells. An each cell can be addressed by its index within the grid. For instance, cell [2,5] is located in the second row and in the 5th column. The first row can contain fields to group data by them. The second row contains field headers. However in the general case the table header may consist of more than one row. Moreover, we have a special column marked "#". By clicking a link from this field, we can enter the edit mode for the particular database record.

By clicking the Calc Ages button, we invoke calculating ages on the server. After finishing calculations, the server saves these values to the database and refreshes the web page.

The Clear Ages button deletes all calculated ages from the database.

How we can obtain values from the grid? First of all we can obtain the table object and then call the appropriate methods and properties to get the information about it. For instance, we can obtain the number of columns in the grid using the ColumnCount property. Similarly, the number of rows is contained in the RowCount property. To obtain the particular value stored in a cell, we can use the cell’s innerText property. So we can implement some helper routines in the WorkingWithGrid unit to use them further in functional tests.

We can find the number of any column by its name. We will search the name as a header cell’s inner text. And then, after we have found matched text we can obtain the column index of the cell:

We can obtain the row number in the same way:

We can also obtain a value from the table by some key value. For instance, we need to obtain Davolio’s phone number. In this case, "Phone Number" is a key field, and "Davolio" is a key value. So, we should obtain the "Phone Number" column number and the row number with the information about Davolio. After that using these column and row number we can get the needed value:

Now we are able to simulate user actions over the page from script. The following code simulates selecting/deselecting a row from the grid depending on the check parameter. We use the ClickChecked method to simulate checking/unchecking the appropriate checkbox:

Checking the ability to modify data in the grid is a common testing task. To be able to change data in our grid, we should enter the edit mode for the specified row. We can do this by clicking the Edit link in the row. However, to click the link we should firstly find the appropriate link within the table:

Our tested page has two buttons – Calc Ages and Clear Ages. We should also check their functionality. To click a button you can use the Click method:

After that we can create methods selecting all rows from the table, unselecting rows and so on. The full text of WorkingWithGrid unit you can find in the source code. You can also use these routines, maybe with some modifications according to peculiarities of your grid, in your projects.

Now all helper routines are implemented, we can construct the complete functional tests.

Writing Functional Tests

We will define 6 functional tests in the Tests unit. Each test will check a particular functionality. To begin writing script code, we should create the Tests unit and add the following declarations at the beginning of the unit:

Now we can write tests using the routines defined in the WorkingWithGrid unit. The functional tests are script routines looking like the following:

After the tests are ready, we will automate the testing process by configuring the project’s test items. You can also record the desired actions with TestComplete and then execute them like the functional tests.

Automating Tests

As the tests are ready, we can continue preparing the testing project. Now we should create two simple keyword tests automating the following actions:

• Launching the browser
• Loading the tested page
• Closing the browser

Lanching the Browser

We will use keyword tests only for automating actions over the browser. However, you can implement functional (and any other) tests as keyword tests. In this case, you need not write any script code, you can visually construct tests just by inserting the appropriate operations into it.

Now we will implement launching the browser from the RunningBrowser keyword test. To do this, perform the following steps:

1. Add a new keyword test to the project. For instance, name it "RunningBrowser".
2. Add the Run TestedApp operation to the test and specify IEXPLORE as the parameter:

   
   
   Picture 7 – Specifying the Application for the TestedApp Operation

3. Click Finish. Now we can automate starting the browser using this test:

   
   
   Picture 8 – The RunningBrowser Test

As you can see, we also added the Log Message operation to post a message to the test log during the execution.

Closing the Browser

Now we can automate closing the browser with another keyword test. Further we will use this test immediately after finishing functional tests:

1. Add a new keyword test to the project. For instance, name it "ClosingBrowser".
2. Add the ProcessAction operation to the test and specify the IEXPLORE process as the parameter:

   
   
   Picture 9 – Specifying a Process for the Process Action Operation

3. Click Finish and then save changes to the project. The ClosingBrowser test will look like the following:

   
   
   Picture 10 – The ClosingBrowser Test

Now all testing actions are implemented and everything is ready for functional testing of our web page. We should only specify a test execution sequence for the project.

Specifying the Project Test Items

We can easily run a group of tests just by running a project. To do this, we should specify the sequence of tests for the project, or, in other words, project test items. You can do this by performing the following actions:

1. Right-click the ASP.NETPageTesting in the Project Explorer panel.
2. Select Edit | Test Items from the context menu. After that the Test Items page will appear:

   
   
   Picture 11 – The Test Items Page

3. Click New Test Item from the toolbar.
4. In the ensuing dialog select the test to be executed. The first test for our project is RunningBrowser:

   
   
   Picture 12 – Selecting the RunningBrowser Test

5. Click OK.
6. In the same manner, make the list of test items as it is shown in the picture:

   
   
   Picture 13 – Project Test Items

Now the testing project is complete, and you can run all these tests just by running the project:

Picture 14 – Running the Project

After we run the project, TestComplete will do all testing job for us: launching the browser, loading the tested page, executing tests, closing the browser after finishing tests and saving results to the test log. Enjoy testing!

Running ASP.NET Tests

Now we will see how TestComplete automates the testing process.

To start testing, you can just run the ASP.NETPageTesting project. After some time you will get the test execution log:

Picture 15 – The Test Log

This log means that the functional testing of the ASP.NET page has been finished, and you can analyze the obtained results to make an appropriate decision (whether the page works as needed, does the page require revising and so on). Log messages are organized into groups by test items from which they have been posted (see the picture above).

Conclusion

TestComplete provides useful methods and properties making the creation of functional tests easier and more effective. Using TestComplete, you can create powerful automated tests for checking the functionality of dynamic web pages, for instance, ASP.NET pages. You can also easily automate the QA testing process with TestComplete. If you haven’t tried TestComplete, download and try it today.