Script Developer

Naming and Tags

The easiest way for you to structure your test suite is to name the test cases according to a common naming convention. It’s common to start the name with a capitalized T and continue with the so-called “camel-case” where each element’s initial letter is capitalized within the compound word. A best-practice example is to specify the test case’s purpose by compounding single elements, for instance TCartCheckoutCancel, TCartOrder, and so on.

Script Developer allows you to tag test cases and modules. Each test case can have several tags. Tags help to group several test cases and make them easier to find. The list of available test cases can be filtered by tag and name.

Script Packages

Script Developer lets you define packages to structure your test cases and modules in the script explorer. You can use this feature to bundle test cases for similar purposes. The packages may be created having a hierarchical structure, but they are always displayed in flat representation (e.g. testcases.cart.order).

Script Modules to Structure Test Cases

To structure a single script test case, you should use modules. A module is a sequence of script commands. It can be reused in several test cases and call other modules, that is they can be nested. Using modules prevents you from writing or recording the same sequence of commands over and over again. It also helps to keep the test case clear and comprehensive because a module call can be folded to hide the contained commands and display the module’s name only.

Action Commands

While recording, Script Developer automatically inserts so-called Actions. You can also insert a new action manually at any position of your test case. Even though actions look similar to comments or other structuring elements, they are in fact not meant to visually structure your scripts. See the action-related notes in the Script Developer chapter for details.

Java Code

If you decide to choose an approach that requires to write your test cases in Java, you will have the same options to structure your code as in any other Java program or software development project. Feel free to extract sequences of your test case code to methods, to create Java classes, or to use packages to structure your test suite.

Package Suggestions

The <testsuite>/src directory contains subdirectories with the structure of your Java packages in the standard manner. Your source code should be organized in main packages. Typically, one individual package should be created for test cases, for actions, for flows, for validators, and for utility classes. The resulting directory structure might look like this:

  • <testsuite>/src/.../actions (only when XLT Action API is used)
  • <testsuite>/src/.../flow
  • <testsuite>/src/.../util
  • <testsuite>/src/.../validators
  • <testsuite>/src/.../tests

If you plan to use more than one of the approaches provided by XLT, it’s recommended to create packages for each of its test cases, which generates up to three additional subdirectories. Your packages could be named as follows:

  • <testsuite>/src/.../tests/actionbased
  • <testsuite>/src/.../tests/scripting
  • <testsuite>/src/.../tests/webdriver

Besides these options, each approach also introduces XLT-specific framework conditions structuring your test suite and test cases. In particular, each test case is necessarily implemented as a Java class extending an XLT test case class, which is approach-specific and contains one method annotated with ()Test@. See the following sections for such specific framework conditions and further ways of structuring.

Structuring Scripting API and WebDriver Test Cases

When you export a script test case from Script Developer to Java using the XLT Scripting API, it will be converted into a test case class extending AbstractWebDriverScriptTestCase. Modules are converted to classes extending AbstractWebDriverModule. The test case class and all module classes are created automatically and you generally don’t have to deal with their creation.

If you’ve decided to write the test cases from scratch using the WebDriver API, your test case class should extend AbstractTestCase. Like all test case classes, it can have several methods, but exactly one method has to be annotated with ()Test@. This class usually contains the statements and lines of code defining the basic structure of the test case, that is the page flow.

For both approaches, XLT Scripting API and WebDriver API, it’s recommended to structure the page flow by actions. This is especially important if you plan to run a load test because the load test reports are designed for analysis and evaluation based on XLT actions.

The XLT Scripting API offers a very simple command to start a new action: startAction("MyNewAction"). When solely using the WebDriver API, the following line of code starts a new action: Session.getCurrent().setWebDriverActionName("MyNewAction").

Again, be aware that actions should only be used to represent the page flow. See the basic concepts of the XLT framework for details.

Structuring XLT Action-Based Test Cases

Test cases based on the XLT Action API are closely related to actions. As in all other approaches, an action interacts with the current page and, as a result, loads the next page. The latter is associated with this action and becomes the current page for the next action in the test case. In contrast to previous approaches, however, an action is now implemented as a Java class extending AbstractHtmlPageAction. These XLT action classes can be seen as reusable building blocks to write your test case and define the page flow.

See XLT Action API for more information on how the API forces you to structure code and validations by implementing methods.

Creating a Flow

When creating XLT test cases, you sometimes might want to reuse blocks of code containing more than one single action. Just like for modules, you can create your own class with one method that combines a sequence of several XLT actions as a flow. Different test cases can call this method now to reuse the flow. This is a concept for code structuring you can implement if needed, yet explicit support is neither available in the XLT framework nor necessary when you manually create a flow.

Flows will be created automatically only if you export script modules containing more than one action to the XLT Action API.