The video
'Scripting in QF-Test (Basics)'
explains the basic concepts about scripting.
If you want to know more about scripting have a look at the video 'Scripting in QF-Test (Advanced)
explains the basic concepts about scripting.
One of QF-Test's benefits is that complex tests can be created without writing a single line
of code. However, there are limits to what can be achieved with a GUI alone. When testing
a program which writes to a database, for example, one might want to verify that the
actual values written to the database are correct; or one might want to read values from a
database or a file and use these to drive a test. All this and more is possible with the
help of powerful scripting languages like Jython, Groovy or JavaScript.
4.2+
While Jython is supported since the beginning of QF-Test, Groovy has found its way into
QF-Test a bit later (QF-Test version 3). This language might be more convenient than Jython
for those who are familiar with Java. Version 4.2 enabled JavaScript
which might be more suitable for web developers. It's mainly a matter of individual preference
whether to utilize Jython, Groovy or JavaScript scripting inside QF-Test.
In this chapter the basics of the scripting features
available in all supported languages are explained.
Most of the examples can be applied exactly or with few changes in other script languages.
Methods calls which vary in syntax are exemplified in the affected languages.
Particularities of the script languages are described in the sections
Fundamentals of the Jython integration, Scripting with Groovy and Scripting with JavaScript.
3.0+
The scripting language to use for a given 'Server script' or
'SUT script' node is determined by its 'Script language'
attribute, so you can mix all three languages within a test-suite. The default language to use
for newly created script nodes can be set via the option Default script language for script nodes.
The approach to scripting in QF-Test is inverse from that of other
GUI test tools. Instead of driving the whole test from a script, QF-Test
embeds scripts into the test-suite. This is achieved with the two
nodes 'Server script' and 'SUT script'.
Both nodes have a 'Script' attribute for the
actual code.
3.0+
The internal script editor has some useful features to ease the typing of
code. Reserved keywords, built-in functions, standard types, literals and
comments are highlighted. Indentation is handled automatically inside of
code blocks. With [TAB] and
[Shift-TAB] respectively several selected
lines can be indented manually.
However, the probably most useful feature - at least for the QF-Test newbie - might be the
input assistance for many built-in methods. Type, for example, rc.
and
maybe some initial letters of a method name. Then press [Ctrl-Space] to open a pop-up window displaying the appropriate methods and descriptions
of QF-Test's run-context (cf. chapter 45). Select one of the
methods and confirm with [Return] to insert it into the script
code. To get a list of all objects equipped with help, just press [Ctrl-Space] with the mouse cursor positioned after white space.
'Server scripts' are useful for tasks like calculating the values
of variables or reading and parsing data from a file and using it to
drive a test. 'SUT scripts' on the other hand give full access
to the components of the SUT and to every Java API that the SUT
exposes. An 'SUT script' might be used to retrieve or check
values in the SUT to which QF-Test doesn't have access. The 'SUT script'
node has a 'Client' attribute which requires
the name of the SUT client to run in.
'Server scripts' are run in script interpreters
for the different script languages embedded in QF-Test
itself, while 'SUT scripts' are run in a script interpreter
embedded in the SUT. These interpreters are independent of each
other and do not share any state. However, QF-Test uses the RMI
connection between itself and the SUT for seamless integration of
'SUT scripts' into the execution of a test.
Through the menu items »Extras«-»Jython terminal...« or »Extras«-»Groovy terminal...« etc. you can open a window with an interactive command prompt for the
language interpreter embedded in QF-Test. You can use this terminal to experiment with Jython
scripts, get a feeling for the language, but also to try out some sophisticated stuff like
setting up database connections. The keystrokes [Ctrl-Up]
and [Ctrl-Down] let you cycle through previous input and
you can also edit any other line or mark a region in the terminal and simply press
[Return] to send it to the interpreter. In that case QF-Test
will filter the '>>>' and '...' prompts from previous interpreter output.
Similar terminals are available for each SUT client. The respective menu items
are located below the »Clients« menu.
Note When working in a SUT script terminal, there's one thing you need
to be aware of: The commands issued to the interpreter are not executed on the event
dispatch thread, contrary to commands executed via 'SUT script'
nodes. This may not mean anything to you and most of the time it doesn't cause
any problems, but it may deadlock your application if you access any Swing or SWT
components or invoke their methods. To avoid that, QF-Test provides the global method
runAWT
(and runSWT
respectively) that executes arbitrary code
on the event dispatch thread. For example, to get the number of visible nodes in a
JTree
component named tree
, use
runAWT("tree.getRowCount()")
(or runAWT { tree.getRowCount() }
in Groovy) to be on the safe side.
When executing 'Server scripts' and 'SUT scripts', QF-Test provides a special
environment in which a variable named rc
is bound. This variable
represents the run-context which encapsulates the current state of the execution
of the test. It provides an interface (fully documented in section 45.6)
for accessing QF-Test variables, for calling QF-Test procedures and can be used to add
messages to the run-log. To 'SUT scripts' it also provides access to the actual
Java components of the SUT's GUI.
For those cases where no run-context is available, i.e. Resolvers, TestRunListeners, code
executing in a background thread etc. QF-Test also provides a module called qf
with useful generic methods for logging and other things. Please see section 45.7 for details.
One thing the run-context can be used for is to add arbitrary
messages to the run-log that QF-Test generates for each test-run. These
messages may also be flagged as warnings or errors.
|
rc.logMessage("This is a plain message")
rc.logWarning("This is a warning")
rc.logError("This is an error") |
|
| | Example 12.1: Logging messages from scripts | |
When working with compact run-logs (which is strongly encouraged, see the option
Create compact run-log), nodes which most likely will not be needed
for error analysis may be deleted from the run-log to preserve memory. This
does not apply to error messages (rc.logError
). They are kept, along
with about 100 nodes preceding the error. Warnings (rc.logWarning
) are also kept, however, without
preceding nodes. Normal messages (rc.logMessage
) may be subject to deletion. If you really
need to make sure that a message will definitely be kept in the run-log you can enforce
this by specifying the optional second parameter dontcompactify
, e.g.
|
rc.logMessage("This message will not be removed", dontcompactify=true)
# or simply
rc.logMessage("This message will not be removed", 1) |
|
| | Example 12.2: Logging messages that will not get removed in compact run-logs | |
Most of the time logging messages is tied to evaluating some
condition. In that case, it is often desirable to get a result in
the HTML or XML report equivalent to that of a 'Check' node. The
methods rc.check
and rc.checkEqual
will do just that:
|
var = 0
rc.check(var == 0, "Value of var is 0")
rc.checkEqual('${system:user.language}', 'en', "English locale required",
rc.EXCEPTION) |
|
| | Example 12.3: Performing checks | |
The optional last argument changes the error level in case of
failure. Possible values are rc.EXCEPTION
, rc.ERROR
, rc.OK
or rc.WARNING
.
QF-Test has different kinds of variables. On the one hand you find variables
belonging to the QF-Test environment and on the other variables of the script languages.
Variables of the script languages are separated in server and SUT side
variables of the specific script interpreter.
The following graphic clarifies theses differences:
To share the different kinds of variables between QF-Test and the script interpreters
provides the rc
object which has several methods for the purpose.
The methods are explained in the next section.
Using QF-Test variables in scripts is not difficult. You can use the run-context's
lookup
method (see section 45.6 for API reference)
whenever you want to access a QF-Test value as a string.
|
# access a simple variable
text = rc.lookup("someText")
# access a property or resource
version = rc.lookup("qftest", "version") |
|
| | Example 12.4: Using rc.lookup to access string
variables | |
To make the results of a script available during further
test execution, values can be stored in global or local variables.
The effect is identical to that of a 'Set variable' node. The
corresponding methods in the run-context are
rc.setGlobal
and rc.setLocal
.
|
# Test if the file /tmp/somefile exists
from java.io import File
rc.setGlobal("fileExists", File("/tmp/somefile").exists()) |
|
| | Example 12.5: Using rc.setGlobal | |
After executing the above example $(fileExists)
will
expand to true if the file /tmp/somefile
exists and to false
if it doesn't.
To clear a variable, set it to None
, to clear all global variables use
rc.clearGlobals()
from a 'Server script'.
Sometimes it is helpful to have a variable available in several scripting
nodes of the same language. If the value of the variable is not a simple string or integer, it is normally not
sufficient to use rc.setGlobal(...)
to store it in a global QF-Test variable
because the value will be converted to a string in the process. Instead, such a variable
should be declared global
as shown in the following example.
|
global globalVar
globalVar = 10000 |
|
| | Example 12.6: Global Jython variable | |
The globalVar
is now accessible within all further scripting nodes of the
same type ('Server scripts' or 'SUT scripts' of the same client). For changing
the value of globalVar
within another script, the global
declaration is necessary again. Otherwise, a new local variable is created instead of
accessing the existing global. Use the del
statement to remove a global
Jython variable:
|
global globalVar
del globalVar |
|
| | Example 12.7: Delete a global Jython variable | |
In Groovy and JavaScript the global variables declaration is even easier than in Jython.
All variables that are not declared locally are assumed to be global.
|
|
| | Example 12.8: Defining a global variable in Groovy or JavaScript | |
|
assert myGlobal == 'global'
def globals = binding.variables
assert globals['myGlobal'] == 'global'
globals.remove('myGlobal')
assert globals.find { it == 'myGlobal' } == null |
|
| | Example 12.9: Usage and deletion of a global Groovy variable | |
Sometimes one would like to use variable values that have been
defined in one interpreter in a different interpreter. For
example, an 'SUT script' might have been used to create a list
of items displayed in a table. Later we want to iterate over that
list in a 'Server script'.
To simplify such tasks, the run-context provides a symmetrical set
of methods to access or set global variables in a different
interpreter. For 'SUT scripts' these methods are named
toServer
and fromServer
. The corresponding
'Server script' methods are toSUT
and
fromSUT
.
The following example illustrates how an 'SUT script' can set
a global variable in the QF-Test Jython interpreter:
|
cellValues = []
table = rc.lookup("idOfTable")
for i in range(table.getRowCount()):
cellValues.append(table.getValueAt(i, 0))
rc.toServer(tableCells=cellValues) |
|
| | Example 12.10: Setting a server variable from an
'SUT script' | |
After the above script is run, the global variable named
"tableCells" in the QF-Test Jython interpreter will hold the array of cell
values.
Note The cell values in the above example are not
necessarily strings. They could be numbers, date values, anything.
Unfortunately Jython's pickle mechanism isn't smart
enough to transport instances of Java classes (not even
realizable ones), so the whole exchange mechanism is limited to
primitive types like strings and numbers, along with Jython objects
and structures like arrays and dictionaries.
For 'SUT scripts' the run-context provides an additional
method that is extremely useful. Calling
rc.getComponent("componentId")
will retrieve the
information of the 'Component' node in the test-suite with
the 'QF-Test ID' "componentId" and pass that to QF-Test's
component recognition mechanism. The whole process is basically the
same as when simulating an event, including the possible exceptions
if the component cannot be found.
If the component is located, it will be passed to Jython, not as
some abstract data but as the actual Java object. All methods
exposed by the Java API for the component's class can now be
invoked to retrieve information or achieve effects which are not
possible through the GUI alone. To get a list of a component's method
see section 5.5.
|
# get the custom password field
field = rc.getComponent("tfPassword")
# read its encrypted value
passwd = field.getCryptedText()
rc.setGlobal("passwd", passwd)
# get the table component
table = rc.getComponent("tabAddresses")
# get the number of rows
rows = table.getRowCount()
rc.setGlobal("tableRows", rows) |
|
| | Example 12.11: Accessing components with rc.getComponent | |
You can also access sub-items this way. If the
componentId
parameter references an item, the result of
the getComponent
call is a pair, the component and the
item's index. The index can be used to retrieve the actual value.
The following example shows how to get the value of a table cell.
Note the convenient way Jython supports sequence unpacking during
assignment.
|
# first get the table and index
table, (row,column) = rc.getComponent("tableAddresses@Name@Greg")
# then get the value of the table cell
cell = table.getValueAt(row, column) |
|
| | Example 12.12: Accessing sub-items with rc.getComponent | |
The run-context can also be used to call back into QF-Test and execute
a 'Procedure' node.
|
rc.callProcedure("text.clearField",
{"component": "nameField", "message" : "nameField cleared"}) |
|
| | Example 12.13: Simple procedure call in Jython | |
In the example above the 'Procedure' named "clearField" in the
'Package' named "text" will be called. The parameter
named "component" is set to the value "nameField" and the parameter
named "message" is set to the value "nameField cleared".
The same example with Groovy syntax:
|
rc.callProcedure("text.clearField",
["component" : "nameField", "message" : "nameField cleared"]) |
|
| | Example 12.14: Simple procedure call in Groovy | |
And in JavaScript:
|
rc.callProcedure("text.clearField",
{"component" : "nameField", "message" : "nameField cleared"}) |
|
| | Example 12.15: Simple procedure call in JavaScript | |
The value returned by the 'Procedure' through a 'Return' node is returned as the
result of the rc.callProcedure
call.
Note Great care must be taken when using
rc.callProcedure(...)
in 'SUT script' nodes. Only short-running
'Procedures' should be called that won't trigger overly complex actions in the SUT.
Otherwise, a DeadlockTimeoutException
might be caused. For data-driven tests where
for some reason the data must be determined in the SUT, use
rc.toServer(...)
to transfer the values to QF-Test interpreter, then drive
the test from a 'Server script' node where these restrictions do not apply.
Many of the options described in chapter 37 can also be set at runtime
via rc.setOption
. Constants for option names are predefined in the class
Options
. It is automatically available for all script languages.
A real-life example where this might be useful is if you want to replay an event on a
disabled component, so you need to temporarily disable QF-Test's check for the
enabled/disabled state:
|
rc.setOption(Options.OPT_PLAY_THROW_DISABLED_EXCEPTION, false) |
|
| | Example 12.16: Example for setOption | |
After replaying this special event, the original value read from the configuration file
or set in the option dialog can be restored by unsetting the option as the following
example shows:
|
rc.unsetOption(Options.OPT_PLAY_THROW_DISABLED_EXCEPTION) |
|
| | Example 12.17: Example for unsetOption | |
NoteBe sure to set QF-Test options in a 'Server script' node and SUT options in
an 'SUT script' node, otherwise the setting will have no effect. The option
documentation in chapter 37 shows which one to use.
You might face a situation where you want to work with a component
which you have to search before working with it. Sometimes recording
all required components can be exhaustive or might be too
complicated. For such cases you can use the method
rc.overrideElement
to set the found component (either
by generic components or via scripting) to a
QF-Test component. Now you can work with the assigned component and use
all available QF-Test nodes.
Let's imagine that we have a panel and we want to work with the first
textfield, but because of changing textfields we cannot rely on the
standard way of the recognition. Now we can implement a script,
which looks for the first textfield and assigns that textfield to
the PriorityAwtSwingComponent
from the standard library
qfs.qft
. Once we have executed that script we can work
with any QF-Test nodes using the PriorityAwtSwingComponent
,
which actually performs all actions on the found textfield.
|
panel = rc.getComponent("myPanel")
for component in panel.getComponents():
if qf.isInstance(component, "javax.swing.JTextField"):
rc.overrideElement("PriorityAwtSwingComponent", component)
break
|
|
| | Example 12.18: Using rc.overrideElement | |
This concept is very useful if you know an algorithm to determine
the target component of your test-steps.
You can find such priority-components for all engines in the
standard library qfs.qft
. You can also find an
illustrative example in the provided demo test-suite carconfig_en.qft
,
located in the directory demo/carconfig
in
your QF-Test installation.
Python is an excellent, object oriented scripting language written in C by Guido van
Rossum. A wealth of information including an excellent Python tutorial is available at
http://www.python.org. Python is a standard
language that has been around for years with extensive freely accessible documentation.
Therefore, this manual only explains how Jython is integrated into QF-Test, not the
language itself. Python is a very natural language. Its greatest strength is the
readability of Python scripts, so you should have no problems following the examples.
Jython (formerly called JPython) is a Java implementation of the language Python.
It has the same syntax as Python and almost the same set of features. The object
systems of Java and Jython are very similar and Jython can be integrated seamlessly
into applications like QF-Test. This makes it an invaluable tool for Java scripting.
Jython has its own web page at
http://www.jython.org. There is also an extensive
tutorial available which may help you get started with this scripting language.
QF-Test uses Jython version 2.7 which supports a large majority of the standard Python
library.
NoteIn Jython QF-Test variables with the syntax $(var) or ${group:name}
are expanded before the execution of the script. This can lead to unexpected behavior.
rc.lookup(...)
, which will be evaluated during execution of the script, is the
preferred method in this case (see subsection 12.2.3.1 for
details).
Modules for Jython in QF-Test are just like standard Python
modules. You can import the modules into QF-Test scripts and
call their methods, which simplifies the development of complex
scripts and increases maintainability since modules are available
across test-suites.
Modules intended to be shared between test-suites should
be placed in the directory jython
under QF-Test's
root directory. Modules written specifically for one
test-suite can also be placed in the test-suite's directory. The
version-specific directory
qftest-5.2.3/jython/Lib
is reserved for
modules provided by Quality First Software GmbH. Jython modules must have the file
extension .py
.
The following Jython module defines a procedure sorting an array of numbers.
|
def insertionSort(alist):
for index in range(1,len(alist)):
currentvalue = alist[index]
position = index
while position>0 and alist[position-1]>currentvalue:
alist[position]=alist[position-1]
position = position-1
alist[position]=currentvalue |
|
| | Example 12.19: The Jython module pysort.py | |
The procedure defined in above module is beeing called in the following
Jython script:
|
import pysort
alist = [54,26,93,17,77,31,44,55,20]
pysort.insertionSort(alist)
print(alist) |
|
| | Example 12.20: Jython script using a module | |
Python comes with a simple line-oriented debugger called pdb
. Among its
useful features is the ability for post-mortem debugging, i.e. analyzing why a script
failed with an exception. In Python you can simply import the pdb
package and
run pdb.pm()
after an exception. This will put you in a debugger environment
where you can examine the variable bindings in effect at the time of failure and also
navigate up to the call stack to examine the variables there. It is somewhat similar to
analyzing a core dump of a C application.
Though Jython comes with pdb
, the debugger doesn't work very well inside QF-Test
for various reasons. But at least post-mortem debugging of Jython scripts is supported
from the Jython terminals (see section 12.3). After a
'Server script' node fails, open QF-Test's Jython terminal, for a failed
'SUT script' node open the respective SUT Jython terminal, then just execute
debug()
. This should have a similar effect as pdb.pm()
described
above. For further information about the Python debugger please see the documentation for
pdb at https://docs.python.org/2/library/pdb.html.
Jython now has a real boolean type with values True
and False
whereas in older versions integer values 0 and 1 served as boolean values. This can
cause problems if boolean results from calls like file.exists()
are
assigned to a QF-Test variable, e.g. "fileExists" and later checked in a
'Condition' attribute in the form $(fileExists) == 1
. Such
conditions generally be written as just $(fileExists)
which works well with
all Jython versions.
All Java strings are sequences of 16-bit characters. Python's original strings are made
of 8-bit characters. Later, unicode strings with 16-bit characters were added. Jython
literal strings like "abc"
are 8-bit, prepending 'u' for
u"abc"
turns them into unicode strings.
In Jython 2.2, Java strings were converted to 8-bit Python strings based on the default
encoding of the Java VM, typically ISO-8859-1 (also known as latin-1) in western
countries. In Jython 2.5, every Java string is now interpreted as a unicode Jython
string. This results in a lot more implicit conversion between 8-bit and unicode
strings, for example when concatenating a Java string - now converted to unicode - and a
literal string like rc.lookup("path") + "/file"
. Most of the time this
works well, but if the literal string contains characters outside the 7-bit ASCII
character-set, things start to get messy. The default encoding for 8-bit Jython
characters can be specified in the option Default character encoding for Jython
with a default of latin-1 for maximum backwards compatibility. On the upside it is now
possible to have default encodings other than latin-1 and to specify literal strings of
characters in international character sets.
One thing to watch out for is existing code of the form
import types
if type(somevar) == types.StringType:
...
The type types.StringType
is the 8-bit string. It does not match unicode
strings. To test whether some variable is a Jython string, regardless of whether it's
8-bit or unicode, change that to
import types
if type(somevar) in types.StringTypes:
...
One new requirement - coming from newer Python versions - is that Python module files
containing characters outside the 7-bit ASCII character must specify the character
encoding to be used in a comment line close to the top of the file, e.g.
# coding: latin-1
Please see http://www.python.org/peps/pep-0263.html for details.
This simple operation is surprisingly difficult in Jython. Given a Java object you would
expect to simply write obj.getClass().getName()
. For some objects this
works fine, for others it fails with a cryptic message. This can be very frustrating.
Things go wrong whenever there is another getName
method defined by the
class, which is the case for AWT Component
, so getting the class name this
way fails for all AWT/Swing component classes.
In Jython 2.2.1 the accepted workaround was to use the Python idiom
obj.__class__.__name__
. This no longer works in Jython 2.5 because it
no longer returns the fully qualified class name, only the last part. Instead of
java.lang.String
you now get just String
. The only solution
that reliably works for version 2.5 is:
from java.lang import Class
Class.getName(obj.getClass())
This also works for 2.2, but it is not nice, so we initiated a new convenience module
with utility methods called qf
that gets imported automatically. As a
result you can now simply write
qf.getClassName(obj)
.
We are going to close this section with a complex example, combining
features from Jython and QF-Test to execute a data-driven test. For
the example we assume that a simple table with the three columns
"Name", "Age" and "Address" should be filled with values read from a
file. The file is assumed to be in "comma-separated-values" format
with "|" as the separator character, one line per table-row, e.g.:
John Smith|45|Some street, some town
Julia Black|35|Another street, same town
The example verifies the SUT's functionality in creating new table rows.
It calls a
QF-Test procedure that takes the three parameters,
"name", "age", and "address", creates a new table-row and fills it
with these values. Then the Jython script is used to read and parse the
data from the file, iterate over the data-sets and call back to QF-Test
for each table-row to be created. The name of the file to read is
passed in a QF-Test variable named "filename". After filling
the table, the script compares the state of the actual table component with
the data read from the file to make sure everything is OK.
|
import string
data = []
# read the data from the file
fd = open(rc.lookup("filename"), "r")
line = fd.readline()
while line:
# remove whitespace
line = string.strip(line)
# split the line into separate fields
# and add them to the data array
if len(line) > 0:
data.append(string.split(line, "|"))
line = fd.readline()
# now iterate over the rows
for row in data:
# call a qftest procedure to create
# one new table row
rc.callProcedure("table.createRow",
{"name": row[0], "age": row[1],
"address": row[2]})
# verify that the table-rows have been filled correctly
table = rc.getComponent("tabAddresses")
# check the number of rows
rc.check(table.getRowCount() == len(data), "Row count")
if table.getRowCount() == len(data):
# check each row
for i in range(len(data)):
rc.check(table.getValueAt(i, 0)) == data[i][0],
"Name in row " + str(i))
rc.check(table.getValueAt(i, 1)) == data[i][1],
"Age in row " + str(i))
rc.check(table.getValueAt(i, 2)) == data[i][2],
"Address in row " + str(i)) |
|
| | Example 12.21: Executing a data-driven test | |
Of course, the example above serves only as an illustration. It is too
complex to be edited comfortably in QF-Test and too much is hard-coded,
so it is not easily reusable. For real use, the code to read and
parse the file should be parameterized and moved to a module, as
should the code that verifies the table.
This is done in the following Jython script with the methods
loadTable
to read
the data from the file and verifyTable
to verify the
results. It is saved in a module named csvtable.py
.
An example module is provided in
qftest-5.2.3/doc/tutorial/csvtable.py
.
Following is a simplified version:
|
import string
def loadTable(file, separator="|"):
data = []
fd = open(file, "r")
line = fd.readline()
while line:
line = string.strip(line)
if len(line) > 0:
data.append(string.split(line,separator))
line = fd.readline()
return data
def verifyTable(rc, table, data):
ret = 1
# check the number of rows
if table.getRowCount() != len(data):
if rc:
rc.logError("Row count mismatch")
return 0
# check each row
for i in range(len(data)):
row = data[i]
# check the number of columns
if table.getModel().getColumnCount() != len(row):
if rc:
rc.logError("Column count mismatch " +
"in row " + str(i))
ret = 0
else:
# check each cell
for j in range(len(row)):
val = table.getModel().getValueAt(i, j)
if str(val) != row[j]:
if rc:
rc.logError("Mismatch in row " +
str(i) + " column " +
str(j))
ret = 0
return ret |
|
| | Example 12.22: Writing a module | |
The code above should look familiar. It is an improved version of
parts of example 12.21. With that module in place,
the code that has to be written in QF-Test is reduced to:
|
import csvtable
# load the data
data = csvtable.loadTable(rc.lookup("filename"))
# now iterate over the rows
for row in data:
# call a qftest procedure to create
# one new table row
rc.callProcedure("table.createRow",
{"name": row[0], "age": row[1],
"address": row[2]})
# verify that the table-rows have been filled correctly
table = rc.getComponent("tabAddresses")
csvtable.verifyTable(rc, table, data) |
|
| | Example 12.23: Calling methods in a module | |
For more complex import of data QF-Test can be extended with existing
Python modules. For example, at http://python-dsv.sourceforge.net/
an excellent module for very flexible CSV import is freely available.
Groovy is another established scripting language for the Java Platform. It was
invented by James Strachan and Bob McWhirter in 2003. All you need for doing Groovy is a
Java Runtime Environment (JRE) and the groovy-all.jar
file. This library
contains a compiler to create Java class files and provides the runtime when using that
classes in the Java Virtual Machine (JVM). You may think of Groovy as being Java with an
additional .jar
file. In contrast to Java, Groovy is a dynamic language,
meaning that the behavior of an object is determined at runtime. Groovy also allows to
load classes from sources without creating class files. Finally, it is easy to embed
Groovy scripts into Java applications like QF-Test.
The Groovy syntax is similar to Java, maybe more expressive and easier to read. When
coming from Java you can embrace the Groovy style step by step. Of course we cannot
explain all aspects of the Groovy language here. For in-depth information, please take a
look at the Groovy home page at http://groovy-lang.org/ or read the excellent
book "Groovy in Action" by Dierk Koenig and others. Perhaps the following tips may help a
Java programmer getting started with Groovy.
-
The semicolon is optional as long as a line contains only one statement.
-
Parentheses are sometimes optional, e. g.
println 'hello qfs'
means the
same as println('hello qfs')
.
-
Use
for (i in 0..<len) { ... }
instead of for (int i = 0; i <
len; i++) { ... }
.
-
The following imports are made by default:
java.lang.*, java.util.*,
java.io.*, java.net.*, groovy.lang.*, groovy.util.*, java.math.BigInteger,
java.math.BigDecimal
.
-
Everything is an object, even integers like '1' or booleans like 'true'.
-
Instead of using getter and setter methods like
obj.getXxx()
, you can
simply write obj.xxx
to access a property.
-
The operator
==
checks for equality, not identity, so you can write
if (somevar == "somestring")
instead of if
(somevar.equals("somestring"))
. The method is()
checks for identity.
-
Variables have a dynamic type when being defined with the
def
keyword. Using def x = 1
allows for example to assign a
String
value to the variable x
later in the script.
-
Arrays are defined differently from Java, e. g.
int[] a = [1, 2, 3]
or
def a = [1, 2, 3] as int[]
. With def a = [1, 2, 3]
you
define a List
in Groovy.
-
Groovy extends the Java library by defining a set of extra methods for many classes.
Thus, you can for example apply an
isInteger()
method to any
String
object in a Groovy script. That's what is called GDK
(according to the JDK in Java). To get a list of those methods for an
arbitrary object obj
, you can simply invoke
obj.class.metaClass.metaMethods.name
or use the following example:
|
import groovy.inspect.Inspector
def s = 'abc'
def inspector = new Inspector(s)
def mm = inspector.getMetaMethods().toList().sort() {
it[Inspector.MEMBER_NAME_IDX] }
for (m in mm) {
println(m[Inspector.MEMBER_TYPE_IDX] + ' ' +
m[Inspector.MEMBER_NAME_IDX] +
'(' + m[Inspector.MEMBER_PARAMS_IDX] + ')')
} |
|
| | Example 12.24: GDK methods for a String object | |
-
Inner classes are not supported, in most cases you can use Closures instead.
A
Closure
is an object which represents a piece of code. It can take
parameters and return a value. Like a block, a Closure
is defined with
curly braces { ... }
. Blocks only exist in context with a
class
, an interface
, static or object initializers, method
bodies, if
, else
, synchronized
,
for
, while
, switch
, try
,
catch
, and finally
. Every other occurrence of
{...}
is a Closure
. As an example let's take a look at the
eachFileMatch
GDK method of the File
class. It takes two
parameters, a filter (e. g. a Pattern
) and a Closure
. That
Closure
takes itself a parameter, a File
object for the
current file.
|
def dir = rc.lookup('qftest', 'suite.dir')
def pattern = ~/.*\.qft/
def files = []
new File(dir).eachFileMatch(pattern) { file ->
files.add(file.name)
}
files.each {
// A single Closure argument can also be referred with "it"
rc.logMessage(it)
} |
|
| | Example 12.25: Closures | |
-
Working with
Lists
and Maps
is simpler than in Java.
|
def myList = [1, 2, 3]
assert myList.size() == 3
assert myList[0] == 1
myList.add(4)
def myMap = [a:1, b:2, c:3]
assert myMap['a'] == 1
myMap.each {
this.println it.value
} |
|
| | Example 12.26: Working with lists and maps | |
Just like Java classes, Groovy source files (.groovy
) can be organized in
packages. Those intended to be shared between test-suites should be placed in
the directory groovy
under QF-Test's root directory. Others that are written
specifically for one test-suite can also be placed in the directory of the test-suite. The
version-specific directory qftest-5.2.3/groovy
is reserved for
Groovy files provided by Quality First Software GmbH.
|
package my
class MyModule
{
public static int add(int a, int b)
{
return a + b
}
} |
|
| | Example 12.27: MyModule.groovy | |
The file MyModule.groovy
could be saved in a sub directory my
below the suite directory. Then you can use the add
method from
MyModule
as follows:
|
import my.MyModule as MyLib
assert MyLib.add(2, 3) == 5 |
|
| | Example 12.28: Using MyModule | |
This code also shows another groovy feature: Type aliasing. By using
import
and as
in combination you can reference a class by
a name of your choice.
JavaScript has become the most widely used programming language in the web area
and is one of the most popular script languages.
QF-Test supports scripting with ECMAScript, which provides a common standard
for the variety of different implementations of JavaScript.
QF-Test must run with at least Java 8 to use JavaScript.
It is possible to write code for the ECMAScript 6 standard.
QF-Test automatically transpiles the code to the EcmaScript 5 standard before the execution.
Special features of JavaScript as compared to other programming languages:
-
There are two different null values:
undefined
and null
.
A variable is undefined
when it has no value.
null
is an intended null value that has to be assigned.
-
The
==
operator checks for equality instead of identity. So you can use
if (somevar == "somestring")
to check for equality.
To check for identity use the ===
operator.
-
Variables declared with the
let
keyword are dynamically typed.
E.g. let x = 1
makes it possible to assign String
to x
. Constants can be declared with const
.
The following example shows how functionality can be transfered in a module.
The module must be placed in the javascript
directory inside the QF-Test root directory.
The module can look like this:
|
var fibonacci = function(n) {
return n < 1 ? 0
: n <= 2 ? 1
: fibonacci(n - 1) + fibonacci(n - 2);
}
function sumDigits(number) {
var str = number.toString();
var sum = 0;
for (var i = 0; i < str.length; i++) {
sum += parseInt(str.charAt(i), 10);
}
return sum;
}
// Module exports (Node.js style)
exports.fibonacci = fibonacci;
exports.sumDigits = sumDigits; |
|
| | Example 12.29: The moremath.js module | |
The moremath.js
module defines the two function:
fibonacci
and sumDigits
.
Each function has to be exported to .
This can be achieved via Node.js like function exports
.
The following code can now be used inside the script node to take advantage of the moremath.js
modules functions:
|
moremath = require('moremath');
console.log(moremath.fibonacci(13));
console.log(moremath.sumDigits(123)); |
|
| | Example 12.30: Usage of the moremath.js module | |
There are multiple ways to import modules. Modules provided by QF-Test can be imported using the import
function.
|
import {Autowin} from 'autowin';
Autowin.doClickHard(0, 0, true); |
|
| | Example 12.31: Using the autowin module | |
Java classes can also be imported using the import function.
|
import {File} from 'java.io'; |
|
| | Example 12.32: Importing Java classes | |
It is also possible to use the "require" function for importing npm modules,
which are explained in the following section.
npm is a package manager for JavaScript with over 350.000 packages. The available packages are listed here https://www.npmjs.com/.
The packages can be used in QF-Test scripts. They need to be installed in the javascript
folder of the QF-Test root directory.
npm install underscore
This line installs the npm underscore package from the os command line.
There are a few npm modules that are incompatible with the ECMAScript standard
as they were written for Node.js.
|
_ = require('underscore');
func = function(num){ return num % 2 == 0; }
let evens = _.filter([1, 2, 3, 4, 5, 6], func);
console.log(evens); |
|
| | Example 12.33: Usage of the 'underscore' package | |
Besides console.log()
there is another method implemented in QF-Test to show output on the terminal.
Note that this print
is not defined in ECMAScript and was added for convenience in QF-Test.
|
|
| | Example 12.34: Printing an array | |
JavaScript scripts are not executed inside the browser but in a specific
engine on the server or SUT side.
This engine is called Oracle Nashorn Engine and comes with JDK 8.
It allows the execution of EcmaScript directly in the JVM.