Introduction

While there are a lot of ‘right’ ways to use AscentialTest to build tests, we are often asked to provide ‘Best Practices’. This paper provides a summary of the approach and techniques that we use in Zeenyx Support. We hope that it is helpful to your teams as they design manual and automated tests.

Best Practices for building App Object definitions:

1. App Objects for top level windows (MainWin, DialogBox, MDIChild, TopWin) should have a unique path:

In applications where several or all pages share a caption, this is a common issue. The best way to determine if your top level windows have a unique path is to move through a series of snapshots for your top level windows and confirm that a green checkmark displays only for the associated app object definition. If more than one window is matched, you will should add a ‘contains’ clause to the path statement. Select a child object that exists only on the page that you are defining to construct an effective ‘contains’ clause.

1. There should never be duplicate App Objects at any level of the object hierarchy. Do not create a new top level window when your application adds fields to a page already defined. Simply add the new objects. An App Object for a top level window may contain a composite of the possible child objects that it may contain.
2. Create multiple App Objects files:

A new AscentialTest project includes a single App Object file but if you have multiple members of your testing team, all updating that single file, there can be a lot of situations where merging will be necessary. In order to reduce the number of merges needed, create multiple App Object files. You might separate them by module or subsystem of the target application.

1. Name objects to be consistent with what is displayed on the page/screen/window:

AscentialTest usually creates object names that reflect what is displayed but since the name is generated using the attribute that is used to form the path statement, it is highly dependent upon names that developers have used for the various attribute values. In those cases, the Object Name should be modified to reflect the label that is used on the application page/screen/window.

1. Use classes to contain App Objects that exist on multiple pages/screens/windows.

Some applications are designed where some of the application elements are displayed on many or all pages. This is typical for navigational links or search components. Rather than duplicating App Object definitions for those elements, it is better to create a class to contain those objects and then change the class of the top level windows to inherit from that class.

1. Create selectors that are specific to columns.

With the exception of the web table wizard, when tables are defined by AscentialTest through drag and drop, a general selector with the parameter ‘Text’ is created. While this selector will function appropriately in most situations, it is better to constrain the selector to work only on a single column. This approach resolves an ambiguity issue when more than one table column contains the same value, causing the selector to fail. Furthermore, you may want to create multiple selectors, one for each column that you might use in selecting a row. Then you can combine the use of the selectors in your steps when a row needs to be selected using more than one selector.

Best Practices for building Steps:

1. Don’t duplicate sets of actions:

One of the primary design objectives for AscentialTest is to provide a testing solution that minimizes test maintenance. Steps are central to achieving that goal. It is a mistake to duplicate a set of actions in more than one place in your testing project. It is better to encapsulate sets of actions in reusable steps. This approach isolates changes in your testing project to a single step when the business or application logic is modified. The key to making steps reusable it to use parameters for your test data instead of hard-coding data into the step.

1. Design step scope to promote reusability:

Learning how to decide on the scope of a step takes time. When designing a step, consider how it can be reused in many tests. Making the scope of a step too broad will limit its application in other tests. A general rule of thumb is to create a step per page in the target application. We make exemptions to that rule when the actions needed to complete a common task are distributed across multiple pages.

1. Create multiple step files:

A new AscentialTest project includes a single Steps file but if you have multiple members of your testing team, all updating that single file, there can be a lot of situations where merging will be necessary. In order to reduce the number of merges needed, create multiple Step files. You might separate them by module or subsystem of the target application.

1. Name steps using an active verb.
2. Make use of the ‘Group’ field in the Step Editor to organize steps by group.
3. Never use the ‘IsPresent’ action to determine if a top top-level window esists:

To wait for a top-level window to display, use ‘WaitUntilExists’ instead of ‘IsPresent’. The ‘WaitUnitExists’ action works on a tight loop where AscentialTest takes new snapshots on an interval until the specified timeout elapses. It is intended for synchronization. The ‘IsPresent’ action is not to be used for synchronization. It acts upon the current snapshot. It can be used for objects contained objects when the current page is already displayed.

1. Enable auto snapshot when verify fails:

Make use of the project setting to configure AscentialTest to always take a snapshot when a ‘Verify’ fails. You can also enable the feature locally for each ‘Verify’ action that you use. If you are constructing your own verification actions, consider calling UA.LogSnapshot.

Best Practices for building Tests:

1. Tests should primarily be comprised of reusable steps.
2. Create multiple test files:

A new AscentialTest project includes a single Tteps file but if you have multiple members of your testing team, all updating that single file, there can be a lot of situations where merging will be necessary. In order to reduce the number of merges needed, create multiple Test files. You might separate them by module or subsystem of the target application.

1. Make use of the ‘Group’ field in the Test Editor to organize steps by group.
2. Use the ‘Bind DataTable’ feature in the Test Editor to create data driven tests.
3. Make use of the Snapshot Series to guide the development of tests.

Best Practices for creating Test Plans:

1. Use Plan Attributes to tag tests so that it is easier to locate them.
2. Organize tests in Plans by subsystem, module or function being tested.
3. Make use of the ‘Group’ field in the Plan Editor to organize plans by group.

Best Practices for Naming:

1. Use camel back notation for naming all components as AscentialTest already does by default when it generates a name for App Objects or Parameters.
2. Remove context or version related information from names.

Zeenyx support welcomes your suggestions to make this document more comprehensive. Please send in your ‘best practices’ to [email protected] so that we can evaluate them for inclusion in our next update.