Unification of descriptive programming and object repository

A computer device may include logic configured to provide a centralized library for descriptive programming and other types of object descriptions to a testing script engine. The descriptive programming library may store test object descriptions for test objects associated with an application under testing. The logic may be further configured to provide a unification layer over all the object description types and to provide inheritance among the objects at the unification layer. The logic may be further configured to store a test object description, associated with a test object, in the descriptive programming library; identify a reference to the test object in a descriptive programming statement associated with the testing script engine; access the stored test object description in the descriptive programming library based on the identified reference to the test object; and identify an application object, associated with the application under testing, based on the stored test object description.

BACKGROUND INFORMATION

A software development process may include a planning process to determine the requirements of a software application or system, a design process that includes developing functional units and writing source code, and a testing process to validate and verify that a particular functional unit, application, and/or software system is functioning properly. Software testing may be used to uncover defects (i.e., “software bugs”) and/or to determine whether the software under testing satisfies particular requirements, such as testability, maintainability, usability, performance, and/or security requirements.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

A testing system may be used to test a software application. The software application, referred to herein as an application under testing (or application under test), may include application objects. An application object may correspond to a functional unit with particular requirements. For example, if the application under testing includes a web page, the application objects may include HyperText Markup Language (HTML) elements, such as a button, a text input box, a clickable image, and/or a hyperlink.

The testing system may perform a test by running a script with respect to the application under testing. The script may specify particular actions that are to be performed on particular test objects. For example, the script may specify that a test object button be clicked or that a particular input string be entered into a test object text input box. When the script is executed, the testing system may need to match the test objects included in the script with application objects included in the application under testing.

In order to match a test object with an application object, the testing system may need to identify an application object that matches a description of a test object. A description of a test object may include, for example, a list of one or more properties, and corresponding one or more property values, for the test object. Two different techniques may be available in the testing system for matching test objects with application objects.

In one technique, test objects may be included in an object repository. The object repository may correspond to a centralized data store of test objects and descriptions for an application under testing. An object description in the object repository may include a list of properties for the test object along with corresponding property values. Thus, a testing script that uses the object repository may only need to specify a test object name and the testing system may obtain the test object description from the object repository and use the test object description to identify an application object in the application under testing. An object repository may thus facilitate testing by providing a centralized store of test objects that may be accessed by multiple test scripts without having to provide a test object description. In another technique, test objects may be specified using descriptive programming. In descriptive programming, a test object description may be included in a script statement. Thus, for example, a descriptive programming script statement may include a list of test object properties and corresponding property values.

While an object repository may provide a more efficient technique of testing an application in many situations, in some situations, descriptive programming may be preferred. As an example, a test object may be associated with a dynamic property (e.g., a property with a property value that may be subject to change) and a descriptive programming statement may be changed to include a different property value, without affecting other descriptive programming statements that include the test object. As another example, multiple identical application objects may require the same operations and an object repository may not be able to distinguish between the identical application objects. As yet other examples, an object repository may not exist, may be incomplete, or may be too large to be efficiently used. Thus, in some situations, use of an object repository may be preferred, while in other situations, use of descriptive programming may be preferred.

However, use of descriptive programming may result in inefficiencies in generating testing scripts, as no centralized store of objects may exist and script writers may need to continue to type in test object descriptions when writing descriptive programming statements. Furthermore, the test scripts may need to be rewritten significantly when changing from the object repository to descriptive programming or when changing from descriptive programming to the object repository.

Implementations described herein relate to providing a descriptive programming library to a testing script engine of a software testing system. In some implementations, the software testing system may correspond to Hewlett Packard Quick Time Professional (QTP). In other implementations, the software testing system may correspond to another software testing system. The descriptive programming library may store test object descriptions for test objects associated with an application under testing. A test object description may include a list of property names and corresponding property values. For example, the descriptive programming library may store a test object description associated with a test object and the testing script engine may identify a reference to the test object in a descriptive programming statement associated with the testing script engine, access the stored test object description in the descriptive programming library based on the identified reference to the test object, and identify an application object, associated with the application under testing, based on the stored test object description. Thus, in other words, the descriptive programming library may include a dictionary of test object definitions.

In some implementations, the stored test object description may be added to the descriptive programming statement in the script. In other implementations, the stored object description may be accessed when the testing script is being executed. Furthermore, the descriptive programming library may support dynamic property values for test object properties that may enable run time instantiation. For example, a test object description may not specify a property value for a particular property, or may specify the particular property only partially, and a reference to a test object in a descriptive programming may specify a property value. The specified property value may be assigned to the property when the script is executed.

Implementations described herein further include a utility library of descriptive programming functions provided to the testing script engine. The testing script engine may identify a reference to a utility function from the utility library and may execute the utility function when the script is executed. The utility library may include, for example, utility functions to return a stored test object description filtered based on a property specified in the reference to the utility function; return an array of object properties associated with a test object; replace a keyword in a stored test object description; add a property to a stored test object description; determine whether a particular property is included in a stored test object description; return a property value included in a stored test object description; and/or to perform another function relating to descriptive programming.

Implementations described herein further include providing a unified user interface layer to the testing script engine. The unified user interface layer may enable a script to reference test object descriptions stored in the descriptive programming library and to also reference test object descriptions stored in an object repository. For example, if a reference to a unified user interface test object is detected in a script, a determination may be made as to whether the unified user interface test object is associated with a test object description stored in the object repository or with a test object description stored in the descriptive programming library. If the unified user interface test object is associated with a description in the object repository, the test object description from the object repository may be used to identify an application object. If the unified user interface test object is associated with a description in the descriptive programming library, the test object description from the descriptive programming library may be used to identify an application object. A unified user interface test object may be associated with a preference. Thus, if a test object description is detected in both the object repository and the descriptive programming library, the test object description may be selected from either the object repository or the descriptive programming library based on the specified preference.

Furthermore, the unified user interface layer may enable the creation of child objects. A child unified user interface layer object of a parent unified user interface layer object may inherit one or more properties from the parent unified user interface layer object. Moreover, the unified user interface layer may provide for method inheritance. A method may perform a particular function in connection with a unified user interface layer object. A second unified user interface layer object may be configured to inherit a method from a first unified user interface layer object.

FIG. 1is a diagram illustrating example components of an environment100according to an implementation described herein. As shown inFIG. 1, environment100may include a testing system110, a network120, and an application system130. Testing system110may perform testing on application system130via network120.

Testing system110may include one or more computer devices configured to perform automated software testing on a software system included in application system130. Testing system110may include an object repository and may be configured to enable descriptive programming. Furthermore, testing system110may include a descriptive programming library and may include a unified user interface layer that unites the descriptive programming library and the object repository. In some implementations, testing system110may include one or more server devices and/or one or more client devices (e.g., desktop computers). The client devices may include one or more mobile computer devices, such as a tablet computer, a laptop computer, a mobile phone, a smart phone, a phablet computer device, a wearable computer device (e.g., a glasses smartphone device, a wristwatch smartphone device, etc.), and/or any other type of mobile computer device with communication functionality and a user interface.

Network120may include one or more circuit-switched networks and/or packet-switched networks. For example, network120may include a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), a Public Switched Telephone Network (PSTN), an ad hoc network, an intranet, the Internet, a fiber optic-based network, a wireless network, and/or a combination of these or other types of networks. Network120may include one or more base stations (not shown inFIG. 1) that provide wireless access to network120for testing system110and/or application system130. For example, the one or more base stations may include a Long Term Evolution eNodeB base station, a Global System for Mobile Communications (GSM) base station, a Code Division Multiple Access (CDMA) base station, and/or another type of base station.

Application system130may include one or more computer devices that include an application under development that is to be tested using testing system110. The application may include, for example, one or more of a web application, a Web services application, a Main frame application, a Java™ application, an Oracle Application™, an ActiveX™ application, and/or another type of application under testing. In some implementations, application system130may include one or more server devices and/or one or more desktop computer devices. In other implementations, application system130may include one or more mobile computer devices, such as a tablet computer, a laptop computer, a mobile phone, a smart phone, a phablet computer device, a wearable computer device (e.g., a glasses smartphone device, a wristwatch smartphone device, etc.), and/or any other type of mobile computer device with communication functionality and a user interface.

AlthoughFIG. 1shows exemplary components of environment100, in other implementations, environment100may include fewer components, different components, differently arranged components, or additional components than depicted inFIG. 1. Additionally or alternatively, one or more components of environment100may perform functions described as being performed by one or more other components of environment100.

FIG. 2is a diagram illustrating exemplary components of device200according to an implementation described herein. Testing system110and/or application system130may each include one or more devices200. As shown inFIG. 2, device200may include a bus210, a processor220, a memory230, an input device240, an output device250, and a communication interface260.

Bus210may include a path that permits communication among the components of device200. Processor220may include any type of single-core processor, multi-core processor, microprocessor, latch-based processor, and/or processing logic (or families of processors, microprocessors, and/or processing logics) that interprets and executes instructions. In other embodiments, processor220may include an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), and/or another type of integrated circuit or processing logic.

Memory230may include any type of dynamic storage device that may store information and/or instructions, for execution by processor220, and/or any type of non-volatile storage device that may store information for use by processor220. For example, memory230may include a random access memory (RAM) or another type of dynamic storage device, a read-only memory (ROM) device or another type of static storage device, a content addressable memory (CAM), a magnetic and/or optical recording memory device and its corresponding drive (e.g., a hard disk drive, optical drive, etc.), and/or a removable form of memory, such as a flash memory.

Input device240may allow an operator to input information into device200. Input device240may include, for example, a keyboard, a mouse, a pen, a microphone, a remote control, an audio capture device, an image and/or video capture device, a touch-screen display, and/or another type of input device. In some embodiments, device200may be managed remotely and may not include input device240. In other words, device200may be “headless” and may not include a keyboard, for example.

Output device250may output information to an operator of device200. Output device250may include a display, a printer, a speaker, and/or another type of output device. For example, device200may include a display, which may include a liquid-crystal display (LCD) for displaying content to the customer. In some embodiments, device200may be managed remotely and may not include output device250. In other words, device200may be “headless” and may not include a display, for example.

Communication interface260may include a transceiver that enables device200to communicate with other devices and/or systems via wireless communications (e.g., radio frequency, infrared, and/or visual optics, etc.), wired communications (e.g., conductive wire, twisted pair cable, coaxial cable, transmission line, fiber optic cable, and/or waveguide, etc.), or a combination of wireless and wired communications. Communication interface260may include a transmitter that converts baseband signals to radio frequency (RF) signals and/or a receiver that converts RF signals to baseband signals. Communication interface260may be coupled to an antenna for transmitting and receiving RF signals.

AlthoughFIG. 2shows exemplary components of device200, in other implementations, device200may include fewer components, different components, additional components, or differently arranged components than those depicted inFIG. 2. Additionally or alternatively, one or more components of device200may perform one or more tasks described as being performed by one or more other components of device200.

FIG. 3is a diagram illustrating exemplary functional components of testing system110according to an implementation described herein. The functional components of testing system110may be implemented, for example, via processor220executing instructions from memory230. As shown inFIG. 3, testing system110may include a test script engine310, a unified user interface layer320, a descriptive programming (DP) library330, an object repository340, and a utility and method library350.

Test script engine310may enable generation and/or editing of testing scripts. For example, test script engine310may include a text editor configured to receive text input to generate test script statements in a particular scripting language, such as Visual Basic Script (VBScript). Furthermore, test script engine may execute a test script and may access a test object description stored in descriptive programming library330and/or stored in object repository340based on a reference to a test object (e.g., a test object name) included in a script statement. If a test object is defined using unified user interface layer320, test script engine310may access the test object description via unified user interface layer320. In some implementations, test script engine310may access a test object description in descriptive programming library330and may add the test object description to a descriptive programming statement in a script based on a reference to the test object associated with the test object description. During execution of a script, test script engine310may match a test object description with an application object in application system130and may perform one or more actions on the identified application object based on instructions included in the test script in connection with a test object that matches the identified application object.

Unified user interface layer320may provide a unified user interface layer that may be used to define a test object. If a testing script statement includes a reference to a unified user interface layer test object, unified user interface layer320may determine whether the unified user interface layer test object is associated with a test object description in descriptive programming library330or in object repository340and may select the corresponding test object description. If a test object description exists in both descriptive programming library330and object repository340, a test object description may be selected based on a preference associated with the test object.

While implementations described herein correspond to a unified user interface layer that enables a script to reference test object descriptions stored in the descriptive programming library and to also reference test object descriptions stored in an object repository, in other implementations the unified user interface layer may enable a script to reference more than two different object description mechanisms.

Descriptive programming library330may store test object descriptions associated with descriptive programming statements. As an example, a user may type in a test object name and a test object description in a descriptive programming statement and the test object description may be stored in descriptive programming library330. As another example, a user may enter a partial test object description into descriptive programming library. A partial test object description may include one or more dynamic properties. A dynamic property may be associated with a dynamic property value that is defined at run-time based on, for example, a value specified in a test script statement.

Object repository340may store test object descriptions. A test object description may be manually added to object repository340. Additionally or alternatively, object repository340may be populated with test object descriptions by detecting application objects in application system130and by generating test object descriptions based on the detected application objects.

Utility and method library350may include a utility library of descriptive programming functions provided to testing script engine310. Testing script engine310may identify a reference to a utility function from utility and method library350and may execute the utility function when the script is executed. Utility and method library350may include, for example, utility functions to return a stored test object description filtered based on a property specified in the reference to the utility function; return an array of object properties associated with a test object; replace a keyword in a stored test object description; add a property to a stored test object description; determine whether a particular property is included in a stored test object description; return a property value included in a stored test object description; and/or to perform another function relating to descriptive programming. Utility and method library350may also include method definitions associated with test object names applicable to test objects defined in both descriptive programming library330and object repository340through unified user interface Layer330, which may allow methods by the same name to be shared between different test objects or to be customized for individual test objects.

AlthoughFIG. 3shows exemplary functional components of testing system110, in other implementations, testing system110may include fewer functional components, different functional components, differently arranged functional components, or additional functional components than depicted inFIG. 3. Additionally or alternatively, one or more functional components of testing system110may perform functions described as being performed by one or more other functional components of testing system110.

FIG. 4is a diagram illustrating exemplary components that may be stored in descriptive programming library330according to an implementation described herein. As shown inFIG. 4, descriptive programming library330can include one or more object records401. Each object record401may store information relating to a particular test object. Object record401may include an object name field410, an object description field420, one or more child object fields430, and one or more method fields440.

Object name field410may store a name for the particular test object. Object description field420may store the test object description for the particular test object. Object description field420may include one or more property name fields422and corresponding property type fields424and property value fields426. Property name field422may store a property name for a particular property. Property type field424may store a property type for the particular property. The property type may indicate, for example, whether the property is a numerical value, a string value, etc. Property value field426may store a property value or a partially specified property value associated with the particular property. A partially specified value may contain keywords that are replaced at run time. Child object field430may identify child objects associated with the particular test object. Method field440may identify methods (e.g., functions) associated with the particular test object. The methods may be part of the utility and method library350and may be specified on object repository objects by leaving the object description420empty.

AlthoughFIG. 4shows exemplary components of descriptive programming library330, in other implementations, descriptive programming library330may include fewer components, different components, differently arranged components, or additional components than depicted inFIG. 4.

FIG. 5is a flowchart for a first process of using a descriptive programming library according to an implementation described herein. In the process ofFIG. 5, a test object description is added to a descriptive programming statement based on information stored in descriptive programming library330. In some implementations, the process ofFIG. 5may be performed by testing system110. In other implementations, some or all of the process ofFIG. 5may be performed by another device or a group of devices separate from or including testing system110.

The process ofFIG. 5may include providing a descriptive programming library (block510). For example, testing system110may provide descriptive programming library330to test script engine310, enabling a user to store test object descriptions in descriptive programming library330, retrieve test object descriptions from descriptive programming library330, and/or to access stored test object descriptions in descriptive programming library330during script execution.

A test object description may be received (block520) and stored in the descriptive programming library (block530). As an example, a user may store a test object description directly in descriptive programming library330. As another example, a user may enter a test object name and a test object description (e.g., one or more property names and corresponding property values) into a descriptive programming statement using a text editor associated with test script engine310and the test object description may be automatically stored in descriptive programming library330. As yet another example, a user may enter a test object name and a test object description into a descriptive programming statement using a text editor associated with test script engine310, may highlight (or otherwise select) the test object description, and may request to store the selected test object description in descriptive programming library330. Furthermore, the user may select one or more properties included in the test object description as dynamic properties.

A request to add the test object description to a descriptive programming statement may be received (block540). As an example, a user may enter a test object name into a text editor associated with test script engine310and test script engine310may access descriptive programming library330to determine whether a test object description exists for the entered test object name. As another example, a user may request to access a list of test object descriptions stored in descriptive programming library330.

A test object description based on a test object reference included in the descriptive programming statement may be identified (block550) and added to the descriptive programming statement (block560). For example, test script engine310may identify a list of property names, and corresponding property values, associated with the test object name included in the text editor and may add the property names and property values into the text editor. The test object description may be modified to define property values for dynamic properties (block570). For example, the user may enter (or change) one or more property values for dynamic properties associated with the test object description.

Furthermore, a descriptive programming statement may make use of one or more utilities from utility and method library350. For example, the descriptive programming statement may call a utility functions to return a stored test object description filtered based on a property specified in the reference to the utility function; return an array of object properties associated with a test object; replace a keyword in a stored test object description; add a property to a stored test object description; determine whether a particular property is included in a stored test object description; return a property value included in a stored test object description; and/or to perform another function relating to descriptive programming.

An application object may be identified based on the modified test object description (block580) and one or more actions may be performed on the identified application object based on the descriptive programming statement (block590). For example, the descriptive programming statement may specify one or more actions that are to be performed on the test object (e.g., select the test object if the test object is selectable, input a string if the test object corresponds to an input type test object, etc.). When the script is executed by testing system110, testing system110may identify an application object in application system130based on the modified test object description and may perform the specified one or more actions on the identified application object. Testing system110may then record the results of the one or more actions in application system130and may report the results to the user.

FIG. 6is a flowchart for a second process of using a descriptive programming library according to an implementation described herein. In the process ofFIG. 6, a test object description is not added to a descriptive programming statement. Rather, the test object description is accessed in descriptive programming library330when a testing script is being executed. In some implementations, the process ofFIG. 6may be performed by testing system110. In other implementations, some or all of the process ofFIG. 6may be performed by another device or a group of devices separate from or including testing system110.

The process ofFIG. 6may include providing a descriptive programming library (block610). For example, testing system110may provide descriptive programming library330to test script engine310, enable a user to store test object descriptions in descriptive programming library330, retrieve test object descriptions from descriptive programming library330, and/or to access stored test object descriptions in descriptive programming library330during script execution.

A test object description may be received (block620) and a test object description template may be stored in the descriptive programming library (block630). As an example, a user may store a test object description directly in descriptive programming library330. As another example, a user may enter a test object name and a test object description (e.g., one or more property names and corresponding property values) into a descriptive programming statement using a text editor associated with test script engine310and the test object description may be automatically stored in descriptive programming library330. As yet another example, a user may enter a test object name and a test object description into a descriptive programming statement using a text editor associated with test script engine310, may highlight (or otherwise select) the test object description and may request to store the selected test object description in descriptive programming library330. As yet another example, a user may define a unified user interface layer test object using unified user interface layer320and may store the defined unified user interface layer test object in descriptive programming library330. Furthermore, the user may select one or more properties included in the test object description as dynamic properties by adding a template for the selected one or more properties that may be populated at run time with particular property values. Furthermore, a utility function and/or method from utility and method library350may be defined as a method for a test object in descriptive programming library330.

A request to run a descriptive programming script may be received (block640). For example, the user may request to execute a descriptive programming script and testing script engine410may process the descriptive programming script. A test object name in the descriptive programming script may be detected and a test object description based on the detected test object name may be identified (block650). For example, test script engine310may detect a test object name, which does not include a test object description, in the descriptive programming script and may access descriptive programming library330to identify a stored test object description associated with the detected test object name.

Dynamic properties in the test object description template may be populated based on values associated with the test object name in the descriptive programming script (block670). For example, the test object name in the descriptive programming script may be associated with one or more property values specified for one or more properties. Test script engine410may populate the specified one or more properties in the test object description template, associated with the test object, with the one or more property values when executing the script.

An application object may be identified based on the modified test object description (block680) and one or more actions may be performed on the identified application object based on the descriptive programming script (block690). For example, the descriptive programming script may specify one or more actions that are to be performed on the test object. When the script is executed by testing system110, testing system110may identify an application object in application system130based on the modified test object description and may perform the specified one or more actions on the identified application object. Testing system110may then record the results of the one or more actions in application system130and may report the results to the user.

FIG. 7is a flowchart for a process of using a unified user interface for descriptive programming and an object repository according to an implementation described herein. In some implementations, the process ofFIG. 7may be performed by testing system110. In other implementations, some or all of the process ofFIG. 7may be performed by another device or a group of devices separate from or including testing system110.

The process ofFIG. 7may include providing a unified user interface object layer (block710). For example, testing system110may provide descriptive programming library330to test script engine310, enable a script to reference test object descriptions stored in the descriptive programming library and to also reference test object descriptions stored in an object repository.

As an example, a user may define a new unified user interface test object using a unified user interface syntax and may select to store the new unified user interface test object description in either object repository340or descriptive programming library330. As another example, a descriptive programming test object description may be detected in a descriptive programming statement and the description may be stored in descriptive programming library330using the unified user interface syntax. As another example, test objects generated based on detected application objects using an application object detection tool may be stored in object repository340using the unified user interface syntax. As yet another example, test object descriptions stored in either descriptive programming library330or object repository340may be converted into unified user interface test objects using the unified user interface syntax.

A method inheritance syntax (e.g., similar to method inheritance syntax862shown inFIG. 8Fand described below) may be used to inherit methods between objects defined in either descriptive programing library330or object repository340. An object property inheritance may similarly be used to inherit test object properties between objects defined in either descriptive programing library330or object repository340. Method and property inheritance may enable the user to maintain a hierarchy of test objects. A child object may inherit one or more properties from a parent object. Furthermore, the child object may inherit one or more methods from the parent object. As an example, the user may define a first method, and/or first property, for the first child object and may define a second method, and/or second property, for the second test object based on the first method via method inheritance. The unified user interface layer320may enable the method and property inheritance to be used between and among a mix of descriptive programing and object repository object definitions. Such a method and/or property hierarchy may be analogous to a class/subclass hierarchy in other object oriented programming, and may be orthogonal to the containment oriented hierarchy illustrated described below with reference toFIG. 8A(e.g., object repository test object reference812, descriptive programming test object description814, second descriptive programming test object description816, and/or unified user interface test object818). Inherited methods and/or properties may be identified for objects at the unified user interface layer and the identified methods and/or properties may be executed based on parameters included in a script statement.

A unified user interface object layer name may be identified in a script (block720). For example, testing script engine410may identify, in a testing script, an object name in the syntax associated with unified user interface object layer320. A determination may be made as to where the unified user interface object layer name in the script is found (block730). For example, testing script engine410may access object repository340and descriptive programming library330to determine whether an object description associated with the identified object name is stored in either object repository340or descriptive programming library330.

If the unified user interface object name is found in the object repository (block730—OR), an application object may be identified based on a description in the object repository (block740). For example, testing system110may retrieve the stored test object description from object repository340and may identify an application object in application system130using the test object description retrieved from object repository340.

If the unified user interface object name is found in the descriptive programming library (block730—DP LIBRARY), an application object may be identified based on a description in the descriptive programming library (block750). For example, testing system110may retrieve the stored test object description from descriptive programming library330and may identify an application object in application system130using the test object description retrieved from descriptive programming library330.

If the unified user interface object name is found in both the object repository and the descriptive programming library (block730—DP LIBRARY AND OR), a determination may be made as to whether there is a preference for the object repository or for the descriptive programming library (block760). For example, when a user generates a unified user interface object, or when an existing test object description is converted into a unified user interface object, a preference may be selected for the unified user interface object. The preference may indicate either object repository340or descriptive programming library330. The test object description may be selected from either object repository340or descriptive programming library330based on the indicated preference.

If the preference is determined to be for the object repository (block760—OR), an object repository test object description may be used, if found. Otherwise, a descriptive programming library test object description may be used (block770). If the preference is determined to be for the descriptive programming library (block760—DP LIBRARY), a descriptive programming library test object description may be used, if found. Otherwise, a test object description from the object repository may be used (block780).

FIGS. 8A-8Fare diagrams of exemplary testing scripts according to an implementation described herein.FIG. 8Aillustrates a table810that shows exemplary test object descriptions for a test object corresponding to a web element in a web page of a browser. Table810illustrates an exemplary object repository test object reference812. Table810further illustrates a first descriptive programming test object description814written in a first style (e.g., a static inline style) and a second descriptive programming test object description816(e.g., dynamic style using description objects). Table810further illustrates a unified user interface test object818that defines the web element as a child object of the page element, which is defined as the child object of the browser test object. Although the syntax of unified user interface test object818is different from the syntax of object repository test object reference812or first descriptive programming test object description814, in other implementations, the syntax of unified user interface test object818may be different from the syntax of object repository test object reference812and/or first descriptive programming test object description814.

FIG. 8Billustrates a table820that shows a set of descriptive programming statements822that use a description object to define an innertext object (e.g., the text between the start and end tags of an object). A description object may be used in descriptive programming to store the properties and values for a particular object in an instance of that object during run-time. Thus, a description object may be used to define dynamic properties. For comparison, table820illustrates an exemplary descriptive programming library style824that may be used to store the same innertext object in descriptive programming library330. Table820further illustrates a utility tool function associated with a utility tool style826that uses a MakeDescription utility tool that returns a description object for the same innertext object from an array of attributes. Thus, as shown inFIG. 8B, the use of a descriptive programming library style and the utility tool style simplifies writing of test scripts (e.g., one line vs. three lines) while the descriptive programming library style provides a centralized store of descriptive programming test object descriptions.

FIG. 8Cillustrates a table830that shows a set of descriptive programming statements832that use a description object to define an innertext object with dynamic properties. For comparison, table830also illustrates an exemplary descriptive programming library object834, corresponding to the innertext object, that may be stored in descriptive programming library330. Furthermore,FIG. 8Cillustrates a unified user interface object836corresponding to the descriptive programing library object834that may be referenced in a descriptive programming statement. Both descriptive programming library object834and unified user interface object836involve partially specified descriptions, where @name@, @e@, and @i@ in descriptive programming library object834will be replaced at run time by the property values assigned to the name variable, namely “1” and “1”, respectively, as shown in unified user interface object836.FIG. 8Calso illustrates utility tools838that may be used to define dynamic properties for the test object. For example, a GetDescDS utility tool may extract a specified object description while CopyDescription may copy an object description.

FIG. 8Dillustrates a table840that shows a set of descriptive programming statements842that use a description object with a collection of child objects. For comparison, table840further illustrates a unified user interface object844that includes a collection of child objects and a utility tool846that includes a getTestObjects utility function to extract a collection of child objects from an object.

FIG. 8Eillustrates a table850that shows an exemplary method definition syntax852. Table850further shows exemplary method definitions854and method invocation statements in a unified syntax856that include calls to the defined methods.FIG. 8Fillustrates a table860that shows an exemplary method inheritance syntax862.

For example, while a series of blocks have been described with respect toFIGS. 5-7, the order of the blocks may be modified in other implementations. Further, non-dependent blocks may be performed in parallel.

The term “logic,” as used herein, may refer to a combination of one or more processors configured to execute instructions stored in one or more memory devices, may refer to hardwired circuitry, and/or may refer to a combination thereof. Furthermore, a logic may be included in a single device or may be distributed across multiple, and possibly remote, devices.