Imprint
2021 December Release

Basic StructurePermanent link for this heading

A source code file can contain tests and functions. If tests and functions from other files are used, they must be included.

Syntax

include "PATH"

test "TESTNAME" {

  session SESSIONNAME1() {
    section "SECTIONNAME1" {
      run FUNCTIONNAME1()
    }
  }

  session SESSIONNAME2("USERNAME", "PASSWORD") {
  }

  session ("USERNAME", "PASSWORD", location="URL") {
  }

  session ("USERNAME", "PASSWORD", location="URL", cookie="name@url=value") {
  }

  session (applicationtype="JAVA", clienttype="EXTERNAL",
      jarfile="apptest-commander.jar", classname="Commander") {
  }

  session (applicationtype="JAVA", clienttype="EXTERNAL",
      jarfile="apptest-mail.jar", classname="Mail") {
  }

  session (applicationtype="NATIVE", clienttype="NOTEPAD",
      location="WINDOWTITLE", options="LOCKED") {
  }

}

/**
 * Here is the description of this function
 * @param param1 is the first parameter
 * @param param2 is the second parameter
 */
def FUNCTIONNAME1(param1, param2) {
}

Includes

The keyword include allows the reuse of function definitions stored in other files. The path must be written with apostrophes.

The PATH can be defined as follows:

  • Absolute Path
    include "C:/somepath/somefile.apptest"
    • Only the defined file is imported (somefile.apptest).
  • Relative Path (relative to the current file)
    include "somepath/somefile.apptest"
    • Only the defined file is imported (somefile.apptest).
    • The file path is searched in the entire project.
    • The path starts with a name, the leading slash must be omitted.
  • Ant Style Patterns
    include "somepath/**/*.apptest"
    • Every file ending with .apptest is imported from the folder somepath/ (/*.apptest means all files that contain .apptest).
    • With /**/ each subfolder is considered.
    • The file path is searched in the entire project.

The forward slash ("/") should be used in file paths as it is recognized by any operating system, while a backslash is recognized only by Microsoft Windows.

Test Definition

The test block can be named and defines a runnable test. The name of the test block is written under apostrophes and starts with a capital letter (e.g. def MyTestDefinition(){}). If there is exactly one test, it is good practice to name the test according to the file name.

It is also possible to write several test blocks in one file. These blocks are carried out in sequence.

Function Definitions

Function definitions are useful for reusing often needed test blocks (e.g. a login sequence). This facilitates the modularization of tests. Function definitions are called using the following syntax:

run FUNCTIONNAME(param1, param2)

Functions may have parameters. Parameters behave the same way as local variables. If parameters are defined in a function, they do not necessarily have to be used. If no parameters are passed in a function, the argument list can be empty:

run FUNCTIONNAME()

A def block may also contain sessions. A session is used in a def block in the same way as in a test definition (see example above).

If /** is directly typed before a def block, a comment is created above the function (as in the syntax example above). The individual parameters are automatically added to the comment.

Sessions

A session block can be named and serves as a scope for using a web browser or an external application. The session will be closed at the end of the block which implies, for example, that the web browser instance is closed. The parameters username and password can be defined position-based (position one and two) or as all other allowed parameters as named parameters.

Available parameters:

  • username
    The user name used for authentication.
  • password
    The password of the user.
  • location
    The URL to be opened or in case of an opened document the window title of the third-party product.
    Only needed if the default address of the run configuration should be overwritten.
  • cookie
    Before starting the test, set the specified cookie at the optionally specified URL. When using scenarios, the cookie information for users is available in the returned scenario body. Cookies can be used to log in into a domain with a cookie-based login mechanism. The format of the value is <name>@[<url>]=<value>.
  • applicationtype
    The application that should be used.
    Only needed if the default application type of the run configuration should be overwritten.
    Possible values:
    • BROWSER
      Used for an installed web browser.
    • JAVA
      Used for a JAR file that provides functionality.
    • NATIVE
      Used for interacting with a third-party application (closing the window).
  • clienttype
    The client that should be used based on the application type.
    Only needed if the default client type of the run configuration should be overwritten.
    Possible values:
    • APPLE_SAFARI, GOOGLE_CHROME, GOOGLE_CHROME_HEADLESS, MICROSOFT_EDGE_CHROMIUM, MOZILLA_FIREFOX, MOZILLA_FIREFOX_HEADLESS
      (for application type BROWSER)
    • EXTERNAL
      (for application type JAVA)
    • NOTEPAD, ACROBAT, WINZIP, OUTLOOK, MAIL, PAGES, NUMBERS, KEYNOTE, THUNDERBIRD, OFFICE, WINWORD, EXCEL, POWERPOINT, OPENOFFICE, AUTOCAD, AUTOCAD_PROJECT
      (for application type NATIVE)
  • jarfile
    Defines the external JAR file (only used for application type JAVA). Fabasoft app.test provides: apptest-commander.jar (mainly file system operations) and apptest-mail.jar (retrieving e-mails from a mailbox).
  • classname
    The object class that provides the methods (only used for application type JAVA). In case of the JAR files described before the usable object classes are: Commander and Mail.
  • options
    Defines whether the opened document is locked (only used for application type NATIVE).
    Possible values:
    • LOCKED

Sections

A section block can be named and allows a logic structuring of the test, which may improve the readability of the test and test result.

Download PDF

Download PDF