Fluent interface

Motivation

Molybdenum test scripts are hard to read, especially for non technicains. The command structure, name | target | value is not intuitive, the command structure is oriented on the underlying DOM and DOM location techniquies.

Example for non intuitive command structure:

store | 42 | var1 | 42, passed as target parameter is stored in the variable var1 passed as value.

Tests scripts and the resulting report should be understandable an intuitive way.

Exisiting solutions

Fitnesse is giving the ability to formulate test cases in a more or less natural language in a wiki. To getting this working, somebody has to write code interpreting the tables or formulated testcases and driving the tests at the end.

Goals

The goal of the proposed solution is:

• not to need any extra infrastructure like a wiki, a test server, glue code to be written
• test description has to be translated in an executable form fully automatically
• writing test scripts has to be supported by context sensitive auto completion and context sensitive help

Basic concept

Basic concept is oriented on the code completion features of Eclipse.

The difference is, that the proposed solution is based on a natural language rather than a computer language. This means: the grammar of the language has to be adapted to several natural languages like English or German.

The proposed solution should be able to assist forming one command on its own and forming sensible command sequences as well.

Example:
Command: open | http://molyb.org
English: Open the url _http://molyb.org_ in the current window.
German: Öffne die url _http://molyb.org_ im aktuellen Fenster.

Sometimes a parameter in the command has to be splitted to make the sense of the command understandable an intuitive way:
Example:
Command: assertAttribute | id=myelem@class | glob:new*
English: Stop the execution of the testcase with an error, if the value of the attribute with the name class of element with the id myelem is not matching the glob pattern new*.

The structure of the sentences are not equally in all languages any time.
Example: ???

Grammar of the language

Each command is written as exactly one sentence in the natural language.
Following the the underlying command concept, the language is divided in groups:

• assert
  • condition
  • negated condition
• verify
  • condition
  • negated condition
• store
• waitfor
  • condition
  • negated condition
• action
• brick

The language consists of the following components:

• pattern
• locator
• variable value
• value
• literal of the language itself

The language consists of base commands which can have variants. An example is the base command ElementPresent.
Following variants are existing:

• assertElementPresent
• assertElementNotPresent
• verifyElementPresent
• verifyElementNotPresent
• waitForElementPresent
• waitForElementNotPresent
• storeElementPresent

All auto completion search is oriented on the base command. The base command will have keywords associated. These keywords can be part of the base command phrase or totally different words.

For each command, the grammar consists of natural language phrases, a command template and a keyword list.
Natural language phrases can (optionally) exist for:

• assert
• verify
• store
• waitfor
• action

conditions and its negation will be presented by [condition phrase|negated condition phrase].

Natural language phrases can make use of macros to be constructed.
Macros are existing for assert, verify, store and waitFor general phrases.

Placeholders are typed. Types are:
$L: locator, will be constructed out of $LT=$LV, where $LT is the locator type and $LV the locator value
$UV: user typed variable name
$UX: user typed xpath
...
$P: pattern, will be constructed out of $PT:$PV, where $PT is the pattern type and $PV the pattern value
...

Placeholders not substituted are replaced with an empty string.

$L ad $P are subphrases with its own grammar.
For $LT, translation pairs have to be defined for id, name, css, xpath, dom
For $PT, translation pairs have to be defined for glob, regexp, exact

Example:
Macros:
$mV "Mark as failed, if"
$mA "Stop the execution of the testcase with an error, if"
$mWPre "Wait until"
$mWpost "or the timeout is reached"
$mS "Store"

Translation Pairs:
$LTid "with the id"
$LTname "with the name"
$LTcss "matched by the css selector"
$LTxpath "selected by the xpath"
$LTdom "selected by the javascript dom notation"

$PTglob "matched by the glob pattern"
$PTregexp "matched by the regular expression"
$PTexact "exactly matching"

command: ElementPresent|$L|$V
assert: $mA the Element $L can[not] be found on the current page.
verify: $mV the Element $L can[not] be found on the current page.
waitFor: $mWPre the Element $L is [not] present on the current page $mWPost.
store: $mS 'true' in the variable $UV if the Element $L can be found on the current page, 'false' otherwise.
keywords: element,present

User Interface

The cells of command name, target and value will be connected to one cell.
A double click into this cell will open the editor inplace (XUL panel element).
Ctrl+Space will open the auto completion popup.
Pressing Ctrl+Space while the autocomplete popup is open and the editor is empty will toggle through the command groups:

• assert
• verify
• action
• brick
• store
• waitfor
• all
  Subphrases for locators and pattern are having its own autocompletion, a simple dropdown.