Code Metrics

In general, the major part of a test project is scripts. Complex testing frameworks can contain hundreds of thousands of lines of code. At this level, test routines and script units should be well organized within projects and the script code should be written in a good programming style and should conform to the coding conventions used at your company. This helps eliminate all possible problems in the script code and ensure its understandability and maintainability. For instance, you can ensure that all script routines have no more than 100 lines and no more than 5 parameters, that they use named constants instead of hard-coded values, and so on.

TestComplete generates a code summary for individual units as well as entire projects and project suites. The information is displayed under the [Code metrics] node in the Code Explorer panel. The top-level [Code metrics] node holds the project suite statistics, the [Code metrics] node located under the project node holds the project statistics, and the one shown under a unit node holds information about this unit:

The information displayed in the Code Explorer panel is updated as you modify the script code (namely, after the modified code has been re-parsed). This lets you quickly detect and correct possible issues in the newly recorded or written code.

The code metrics include two types of items: code summary and code issues. You can find information on them below.

You can control the recommended metrics for script routines in the Code Explorer Options.

The project suite, project and unit summary are provided by the following items:

Number of lines

Specifies the total number of lines in a unit, all project units and all project suite units. You can use this metric to measure the test script’s creation progress or to estimate the time of creation for new tests.

Note that this metric represents the actual number of lines in a unit (also known as physical lines count), not the number of scripting statements (logical line count). The metric value includes actual code lines as well as comment and blank lines, standalone braces and parenthesis, and so on. For instance, the following code snippet has four lines, though only two code statements:

Number of routines

Specifies the total number of routines in a unit, all project units or all project suite units. This metric lets you estimate the test project’s modularity.

This number does not include nested functions that some scripting languages support. These functions are not counted at all.

Number of units

This metric is included in statistics on projects and project suites only. It specifies the total number of script units in a project or project suite. If a project contains a large number of routines located in a few units, you may want to increase the number of units and organize the routines better.

In addition to the summary information, TestComplete reports potential problems in the script code. All found issues are grouped into several categories. By double-clicking on an issue, you can jump to the corresponding place in the script.

The following categories of issues are available:

Hard-coded Strings

Like magic numbers, hard-coded strings are difficult to maintain. They can also cause problems when porting the test scripts for another language version of the application under test. It is recommended that you use named string constants or variables of string type instead of hard-coded strings. Alternatively, you can store the strings in an external file and read their values at run time (this is one of the basic ideas behind Data-Driven Testing). To eliminate the usage of string parameters when addressing the tested application’s objects, you can map the object names to custom ones by using the Name Mapping feature.

Note, TestComplete does not report strings consisting of only one character (for instance, “ ” or “|”).

Long Param List

This category lists routines that have too many parameters. Such routines are difficult to call and they are likely to cause wrong parameter order or left-out parameters. It is recommended that you revise the data flow in your test scripts and reduce the number of routine parameters to a minimum.

Long Routines

This category holds too long script routines. Such routines are quite difficult to understand and maintain, they can contain duplicated code, and so on. In order to simplify the script understandability and maintenance, it is recommended that you split long routines into smaller ones so that each routine performs a single task.

Magic Numbers

A “magic number” is a hard-coded numeric value used in the script code. Such values make the script logic difficult to understand, because it is not obvious what the specific value means. In addition, it is hard to alter these numbers, because the same number can be used in different places within the script.

It is recommended that you avoid using “magic numbers” in the code (with the exception of 0, 1 and -1; see below). Instead, use named numerical constants or variables that hold the needed values. The constants should have descriptive names in order to reflect the value meaning (for instance, nDaysOfWeek). Since the constants’ declarations are usually placed in the beginning of a routine body or a script unit, it is much easier to modify them than when using hard-coded numbers.

Besides replacing the “magic numbers” with constants or project variables, you can also eliminate them by using simple scripting techniques. For example:

• TestComplete records clicks on some objects as the Click action with coordinates. If the coordinates at which the click should be performed are insignificant, you can safely remove them from the recorded script. In this case, TestComplete will click in the object center:

  TestComplete clicks at the specified object point: Call w1.Click(58, 29)

  TestComplete clicks in the object center: w1.Click

• When iterating through the object’s items, do not use the hard-coded number of items. Instead, use either the predefined constant specifying the number of items, or determine the item count at run time using a special routine or the object’s property that returns this value:

  The loop counter’s end value is hard-coded: ' Click the combo box items one by one For i = 0 To 5   MyComboBoxObj.ClickItem(i) Next

  The loop counter’s end value is calculated at run time: ' Click the combo box items one by one For i = 0 To MyComboBoxObj.wItemCount - 1   MyComboBoxObj.ClickItem(i) Next

In some cases, however, the usage of hard-coded numbers is accepted. For instance, numbers 0, 1 and -1 are often used in loops or as indexes of applications’ objects being addressed via the Window, WaitWindow and other methods. Therefore, TestComplete does not report these three numbers in the Magic Numbers category.

Too Few Comments

This category lists poorly commented routines. Such routines should be more commented so that their functionality is easier to understand for the reader.

Too Many Comments

This category lists overcommented routines. In most cases, such routines contain redundant comments, for example, comments to self-documenting code. It is recommended that you remove comments that are not needed in order to make the routine code shorter and easier to read.

Too Many Variables

This category lists routines that have a lot of local variables defined. Such routines can be difficult to understand and maintain. It is recommended that you make code more modular by splitting complex routines into smaller ones, each performing an individual helper task and using a few local variables.