Terminology.md

layout
default

{% include links %}

• TOC {:toc}

Selenese

command

A step in Selenese [script]. See also {{navAutoGeneratedSeleneseCommands}} and Selenium IDE documentation > Selenium Commands – “Selenese”.

Making terms not test-specific

Selenium and SeLite are not test-specific. However, Selenium IDE GUI and its documentation refers to some features with word test. The following terms make it more general.

case

Case stands for test case. It consists of Selenese [commands][command] and comments. It's an .html file with a special format.

suite

Suite stands for test suite. It refers to (contains) one or more [cases][case]. It's an .html file with a special format.

A suite and any of its cases don't have to be in the same folder. Therefore a case can belong to multiple suites. If a case defines any [functions][function], other cases in the same suite can reuse them.

script

When some functionality applies to both [cases][case] or [suites][suite], SeLite calls them scripts. To differentiate them from Javascript (or other scripts), they are sometimes called Selenese scripts. Some other terms are at TestMethods and TestMethodsTheory.

Side note: SelBlocks used to call Selenese functions (defined by function...endFunction) scripts. (Originally they were defined by script...endScript.) However, both SelBlocks and [SelBlocks Global]/SeLite refer to them as functions rather than scripts.

function

Word function can refer to a Javascript function (whether in Selenium Core scope or not), or to a function defined by [SelBlocks Global]/SelBlocks construct function...endFunction. Where it's unclear, let's call the later Selenese function or script function.

set

Set is a configuration set as per Settings > Sets.

Core scope

Selenium Core scope, or just Core scope, is global scope (as in JavascriptEssential > Scope) in Core extensions and in Selenese scripts.

Implementation notes:

• Core scope is the same as selenium object.
• See also [Extension Sequencer] > Global symbols and strict mode.

Core extension

Selenium Core extension, or just Core extension, extends functionality available to Selenese scripts. It doesn't provide any visual interface. Generally it can be loaded from Selenium IDE or Webdriver. But even if a Core extension is for Selenium IDE only, it's called a Core extension rather than IDE extension. Core extensions from SeLite are like that: they are Selenium IDE-specific and they don't work with Webdriver.

IDE extension

Selenium IDE extension, or just IDE extension, extends GUI of Selenium IDE. It doesn't interfere with Selenese scripts. However, it may provide configuration or other interface used by a Core extension, and those can be packaged together in a Firefox add-on.

Extension of Selenium IDE

This is either a Core extension but for Selenium IDE only, or an IDE extension.

These terms are not SeLite-specific. The goal here is to clarify possible/desirable features and connections between scripts and the tested application. This mentions benefits and shortcomings of various possible approaches.

Automation

Application

What is being controlled or tested, with

• source, libraries, webserver, single sign on etc.
• application data ('test app DB' or just '[app DB]')

Test

Test consists of Selenese [scripts][script], custom [Core extensions][core extension] and [script DB].

Test session

It contains custom runtime variables in the test system, which serve for

• tracking web app user session and page navigation
• temporary storage of loaded/modified test data and generated test input data
• custom test control
• loading/updating records in [script DB]

Knock-on defects

Also 'silent defects' are 'hidden' or mysterious errors, whose buggy effect

• doesn't show up immediately at all, or
• is not initially tested or obvious (because of the scope, complexity etc.)
• but the defect causes incorrect data which affects subsequent operation

Data and databases

Test input data

Also 'input data' is data, that is used by the test, especially

• for inputs/choices that the test enters/selects in the application, or
• that determines webpage navigation during the test

It can be

• from XML using SelBlocks functionality (a part of [SelBlocks Global])
• from SQLite with the help of SeLite object-oriented layer
• random, within a range or from a list of choices, using SeLite Commands

app DB

App DB is an SQLite database (a file). It is the same as the application's database (if in SQLite), or its export to SQLite.

script DB

Script DB is an SQLite database (a file) used by [scripts][script]. (It's not a database containing scripts or steps, neither a database of data to feed the tests.) In automated testing this is the test's expectation of the application data. It's usually populated from an (optionally filtered) export of [app DB]. It is

• the same source as app data - accessed by test read-only. This is not an ideal approach. See TestMethodsTheory > Web app and its test use the same DB.
• a replica of app data as per TestMethodsTheory > Web app and its test have separate DBs. It
  • is separate - not accessed by the application
  • shadows [app DB]
  • gets updated by the test to reflect the changes expected to happen in the app data (see more below)
  • is used by test to navigate and verify the application
  • helps to detect and identify errors in the application or the test.

vanilla DB

Vanilla DB is a database (in SQLite) used for reloading [script DB] and [app DB]. It requires [app DB] to be in SQLite. It's a snapshot of exported [app DB], to which you can revert [script DB] when the [script] and app get out of sync.