Settings ExternalToolsSettings/en

External Tools Settings

These are found in "Settings" - "External Tools".

Expecco may use external programs to provide additional functionality. This dialog allows for the configuration of which executable is used in particular. You may however have personal preferences. Be aware that external tool startup times may be inconvenient.

HTML Viewer

Specify the program which is used to display online help documents. By default (if left blank), the configured web-browser (typically: Firefox, Safari or Internet Explorer) is used. For security reasons, it is recommended to use Firefox or Safari as opposed to Internet Explorer.

PDF Viewer

Specify the program which is used to display generated report documents. By default, the configured PDF viewer (typically: acrobat reader) is used.

Wiki Folder

Should point to this Wiki (and obviously, it does already, otherwise you would probably not read this document). By default, the Wiki pages are accessed via HTTPS (i.e. encrypted SSL on port 443). You can turn this to HTTP, if your firewall does not allow outside connections via ports other than 80 (which is unlikely) or if you have to go through a proxy on port 80.

External Text Editor

Specify the program to edit text attachments. Useful Linux/Unix settings are "xterm -e vi %1" or "xterm -e emacs %1". By default, a built in text editor (FileBrowser) is used.

Starting with rel 20.1, there will be separate fields for code-editing and attachment-editing. If a command is defined in any, an "Open Editor" icon will be shown in the elementary code / attachment code pages respectively.

External CSV Editor

Specify the program to edit CSV attachments. A useful Linux/Unix setting is "/opt/libreoffice/bin/office %1" or another excel-alike calculator which can read and write CSV files. By default, a builtin text editor (FileBrowser) is used.

External ImageEditor

Specify the program to edit image/bitmap attachments. The program should be able to read/write jpeg, png, tiff, gif and bmp images (whatever is present in your attachments). Useful programs are gimp, photoshop or mspaint.
The bitmap editor is mostly used to postprocess captured screen images (cut borders or extract sub images) for object detection from bitmap screens. It is usually not needed for other GUI technologies.

By default, a builtin simple bitmap editor is used; notice that the startup time for the external editor may be inconvenient, so even though it is limited in its features, the builtin bitmap editor is probably a better choice.  

External Script Interpreter Settings

These are found in "Settings" - "Execution" - "External Script Interpreters".

Script interpreters are programs used to execute script action blocks written in various programming languages, such as Java, Node.js, Python, Ruby, TCL etc.
The location (i.e. folder) and name of the executable may depend on the operating system or your particular choice when installed. It may also be required to choose among a number of different installed versions. This dialog configures those language interpreters.

If no special settings are entered here, the corresponding interpreter is assumed to be found along the regular command line path. Thus, if you have ruby installed, and you can execute it from the command line via "ruby --version", then no special setup is needed in this dialog (for ruby).

This is the recommended way to install those external programs: let them install themself at their preferred location and make sure, they are found along your shell's/cmd's PATH.

You may have to install them before starting expecco or restart expecco, so that the PATH is already correct at the time expecco is started.

If you setup your test system this way, you avoid having to edit the settings when your tests are to be executed on another machine, or are automated via a QM system (such as expeccoALM). In general, the more pathes are specified in your settings, the more possible problems appear when later executing the tests on other machines.

Additional Path

Additional path(es) which are appended to the $PATH shell environment variable for external script interpreters. This will be valid eg. for shell scripts, but also for interpreters like python, node etc.

Directories are separated by ":" (colon) in Unix systems, whereas ";" (semicolon) is used in Windows.

Environment Variables

Variables defined in this list will be exported to any script or bridge started by expecco (aka shell variables).

This affects shell and script actions and bridges which are started by expecco. However, any already running bridge or background command must be shutdown and restarted for this to be effective (i.e. the settings as present at the time when a command is started are relevant) .

Notice, that additional values provided at a script action's input pin will take precedence over what is defined in these global settings.

A common variable to export is "LD_LIBRARY_PATH", which might be needed by the CBridge (see below).

Shell (Win32 only)

Specify the program which is used to execute shell scripts.

Under the Windows operating system, a Unix bourne/korn-shell compatible shell has to be installed (for example as part of the cygwin package).

This is only needed if your test suite includes script actions which are written in the Unix shell command language AND your test suites are required to run unchanged under both Windows and Unix operating systems (however, be aware that this still does not guarantee trouble free operation; file pathes and the different sets of available shell command line tools may still make your scripts unportable. A better solution would be to use combined Shell/Batch actions).

If unspecified, the default shell (value of the "SHELL" environment variable, in either an expecco environment in scope or the shell environment) is used.

In most cases, this setting is not required.

Powershell Path

Specify which powershell interpreter to use for Powershell elementary blocks.

Although mostly used in Windows environments, powershell is also available for Unix systems, incl. OS X [1]. However, it will require a Mono CLR environment to be installed.

By default, the powershell command which is found along your PATH setting is used (i.e. the same as found when executing "powershell" on the command line). Of course, you have to have powershell installed on your machine. Notice, that on some systems, the powershell command is named "pwsh".

If unspecified, the value of the "POWERSHELL" environment variable (in either an expecco environment in scope or the shell environment) is used.

This setting is not needed if you do not use any Powershell elementary blocks.

Node.js

These settings are not needed if you do not use any Node elementary blocks.

Node.js Path

Specify which node.js interpreter to use for Node elementary blocks.

By default, the node command which is found along your PATH setting is used (i.e. the same as found when executing "node" on the command line). Of course, you have to have ruby installed on your machine. If unspecified, the value of the "NODEJS_SHELL" environment variable (in either an expecco environment in scope or the shell environment) is used.

Module Path

Path where node modules are searched. This is passed to node in the NODE_MODULES Environment variable.

Execution Directory

Directory in which node is executed (i.e. its "current directory").

NodeRED Module Path

Path where node modules are searched for NodeRED actions. This is passed to node in the NODE_MODULES Environment variable.
Support for direct NodeRED action execution is being developed and not yet released officially.

NodeRED Execution Directory

Directory in which the node interpreted used for NodeRED Actions is executed.
Support for direct NodeRED action execution is being developed and not yet released officially.

Python

Specify which python interpreter to use for Python elementary blocks.

By default, the python command which is found along your PATH setting is used (i.e. the same as found when executing "python" on the command line). Of course, you have to have python installed on your machine.
If unspecified, the value of the "PYTHON_SHELL" environment variable (in either an expecco environment in scope or the shell environment) is used.

This setting is not needed if you do not use any Python elementary blocks.

Python2 and Python3 Settings

Be aware that there exist two partially incompatible python versions (2.x and 3.x) and there exist packages which are compatible with both and also packages which need a particular version. Although Python2.x is about to be obsoleted now, there are still older packages/applications around, which have not yet been ported to 3.x. Expecco deals with thissituation by allowing you to specify which python interpreter to be used for your actions and also to have multiple interpreters (with different versions) running in parallel.

You can skip this section, iff all of your python modules run in Python3.x and only specify one single path/module setup in the top area of the settings dialog (named "Python")

Due to some bad planning in the python community, there were a number of changes between python2.x and python3.x, which may (and usually do) make scripts written for either version incompatible with the other. For example, the following print expression from python2:

print "Hello World from a Python2 script\n"

needs parentheses in python3:

print ("Hello World from a Python2 script\n")

and will lead to a syntax error if executed in python3.

Although it is a good idea to use Python3 (because Python2 is going to be obsolete soon), there are many open-existing libraries for Python2 around. Thus, it may be necessary to specify an explicit interpreter version to be used for python script actions.

If all of your actions depend on the same python interpreter version, it is sufficient to ensure that either the "PYTHON_SHELL" variable is set correctly, or the "Python Path" is defined in the settings to point to the correct interpreter.

However, if you have mixed version scripts (for example, when importing python actions written by another team, which used a different version), you have to specify the python interpreter explicitly for some of the actions.

You can either specify the version in the elementary action itself (language menu for bridged actions or #PYTHON-comment in script actions) or provide the version information dynamically without touching the action itself. The later is a bit more complicated to use, but required if you do not want to modify imported actions.

For this, expecco contains 3 setting fields for the python interpreter: "Python Cmd Path" in the settings or "PYTHON_SHELL" in the shell environment, which are used when no explicit version is required, or if all of your script require the same python version, "Python2 Cmd Path" in the settings (or "PYTHON2_SHELL"), which are used for scripts which have been marked as explicitly requiring python2 and "Python3 Cmd Path" in the settings (or "PYTHON3_SHELL") for scripts which are marked to require python3.

The python version requirements are defined in the environment of the suite/imported library in which the action is defined: a variable named "PYTHON_VERSION", which should be an integer with either "2" or "3" as value specifies the version to be used for ALL of the python actions within that library. Notice, that the environment of the project from which the action was imported is relevant here - not the active environment at execution time, or the suite's top environment. This version number then determines, which of the above setting is to be used (i.e. PYTHON2_SHELL/path or PYTHON3_SHELL/path).

Using that double-indirect mechanism, it is still possible to:

• import multiple libraries with different python-versions requirements
• specify the paths independent of where the python interpreters are installed (i.e. the machine on which the final suite is executed may have different installation paths than the machine on which the imported libraries were developed).

A concrete demo importing libraries which require different python interpreter versions is found in "d46_Suite_using_both_Python2_and_Python3_actions.ets" in the demo folder.

Notice:
In expecco 19.2, you can also choose the python version in the code editor's language chooser.

Module Path

Specifies where python should look for importable python modules. This is passed to the python executable via the "PYTHONPATH" Environment variable.

Virtual Environment (Directory)

Optionally specifies the virtual python environment in which python actions are to be executed. Use this if you either want to keep your default site-packages unchanged or if you intent to run tests in different python setups. The value specified here will be exported as the VIRTUAL_ENV shell variable. See the Python documentation on doc.python.org for defatails.

Execution Directory

Specifies the directory in which the python interpreter should be executed (i.e. its "current directory").

Compatible Versions

Bridged python actions have been tested with versions 2.7, 3.7 to 3.10; also pypy7-3-9 (which is a 3.9Python) has been verified to work. Please let us know, if newer (or older) versions show any incompatibilites.

Be aware that Python2.x is no longer officially supported (see "Sunsetting Python-2").

Jython and IronPython

These are python interpreters running under the Java Virtual Machine (JWM) or the .NET Common language Runtime (CLR). Jython and IronPython actions are useful to provide interfaces to underlying frameworks using the more pleasing Python syntax. This applies especially to IronPython, as currently no direct C# language support is provided by expecco.

Thus, in order to interface to a .NET assembly, you'd have to use Smalltalk or Javascript actions and refer to .NET objects via remote object proxies. Using IronPython, this is much easier and also easier to debug (you can use the well known logging and debug print facilities inside IronPython).

A similar (but less stringent) argument could be made for Jython, although expecco's support for Java actions (via Groovy) is already very high level and usually better suited for the task.

The settings are described in the above Python section.

CBridge

This setting is not needed if you do not use any C/C++ elementary blocks.

A Step by Step setup documentation is found here.

CBridge Path

Specify which CBridge to use for remote C action execution. The CBridge is responsible for compilation and execution of C action blocks. C actions are dynamically compiled and loaded into the CBridge. For this, a compiler toolchain must be installed on the system (actually, it is also possible to deploy precompiled binaries with the test suite, so C actions can also be executed without a compiler toolchain).

By default, a 32bit CBridge is provided for 32bit expecco systems, and a 64bit CBridge for 64bit expeccos.

Compile Script

For compilation, the CBridge will execute a shell or batch script. Exept provides scripts for the most common toolchains, but you can add your own scripts, taking any existing as a template, and modifying it as required. You will have to create additional compilation scripts if additional libraries or frameworks are to be linked to the code, or if additional compilation flags (defines or optimizer flags) are needed.

Scripts are to be found under the plugin-cBridge folder beneath the expecco installation folder (the settings dialog contains a "Browse" button to open. a file browser on that folder). Notice, that remote C bridges need this script to be present on the target machine, and the remote bridge should be started with a command line argument which defines the script to be used.

If he given script filename has no suffix (i.e. ".sh"or ".bat"), the bridge will add an appropriate suffix automatically. This feature is especially useful, if you have multiple remote bridges running with different operating systems (meaning: both Windows and Unix machines). In this setup, define the script as "compile_default" (without suffix) and make sure that appropriate scripts are present on the target machines.

On Windows, we recommend MINGW as compiler tool chain; on Unix systems (incl. Linux), the default "cc" command is typically used.

Setup for Remote bridges

If the cBridge is running on a remote machine, the script MUST be present there. If you are using multiple cBridge connections to multiple remote machines which have different operating systems and/or different compiler tool chains installed, you should specify "compile_default" as the script, and make certain that the remote machine has a script named "compile_default.bat" or "compile_default.sh" in its cBridge folder. Each remote system's compile script can then be different; however, you have to make sure that those scripts are present and correct.

Connect to Already Running Bridge

This is mostly for debugging; if set, no new bridge is started, but expecco will connect to a running bridge (on either the local or a remote machine).
This can be used to execute the bridge (and with it also your execute function) under a debugger:

• open a terminal window and chdir to "$(INSTALL_DIR)/packages/exept/bridgeFramework/cBridge/cLibrary".
• execute "gdb cBridge" or "lldb cBridge"
• start it with a port parameter: "r --port 8999"
• configure expecco to connect to that already running bridge

Store object files in project

If checked, the generated object code (binary executables) will be stored with the project. When later loaded and executed, these binaries will be used and no attempt is made to compile the C-code dynamically on the target. Use this, if no compiler toolchain is available on the target.

Root Cling

This setting is not needed if you do not use any Cling elementary blocks.

Specify the path to the root command here. On OS X, this is typically "/Applications/root_vx.yy.zz/bin/root", and on Linux "/opt/root_vx.yy.zz/bin/root" or "/use/local/bin/root".

Sorry, but to our knowledge, there is no easy to download/install version available for Windows (yet), although you will find instructions on how to compile it using the MINGW compiler.

Expecco Path

Specify which expecco to use for remote action execution (for load/performance and multi-peer tests). With remote expecco execution, you will be able to specify on a step-by-step basis, on which machine it is to be executed. making it trivial to distribute the execution among a number of machines.

For now, this is an unsupported, unpublished feature to be deployed with a later release.

Smalltalk

This setting is not needed if you do not use any bridged Smalltalk elementary blocks.

Bridged Smalltalk actions should not be confused with the standard Smalltalk elementary actions, which are executed inside expecco. These bridged Smalltalk actions are forwarded to another Smalltalk system, which can be a System under Test (i.e. if you have to test a VisualWorks Smalltalk app) or which can be used to eg. generate load or traffic.

ST/X, VisualWorks and VisualAge Path

Specify which interpreter to use for bridged Smalltalk elementary blocks for various Smalltalk implementations (eXept's Smalltalk/X, Cincom's VisualWorks or IBM/Instantiations' VisualAge).

If a connect-host is specified (in the form "hostname" or "hostname:portNr"), a connection is setup to that machine, assuming that a Smalltalk image is already running there, and the bridge port is served. Otherwise, the given Smalltalk-command is executed, passing a startup script as argument.

For now, this is an unsupported, unpublished feature to be deployed with a later release.

Scheme

Specify which interpreter to use for bridged Scheme elementary blocks. We intent to especially support actions to be executed under Chez Scheme. For now, this is an unsupported, unpublished feature to be deployed with a later release.

Ruby Path

Specify which ruby interpreter to use for Ruby elementary blocks.
Currently only Ruby script actions are supported (i.e. not bridged actions).

By default, the ruby command which is found along your PATH setting is used (i.e. the same as found when executing "ruby" on the command line). Of course, you have to have ruby installed on your machine. If unspecified, the value of the "RUBY_SHELL" environment variable (in either an expecco environment in scope or the shell environment) is used.

This setting is not needed if you do not use any Ruby elementary blocks.

Perl Path

Specify which perl interpreter to use for Perl elementary blocks.
Only Perl script actions are supported (i.e. not bridged actions).

By default, the perl command which is found along your PATH setting is used (i.e. the same as found when executing "perl" on the command line). Of course, you have to have perl installed on your machine. If unspecified, the value of the "PERL_SHELL" environment variable (in either an expecco environment in scope or the shell environment) is used.

This setting is not needed if you do not use any Perl elementary blocks.

TCL Path

Specify which tcsh interpreter to use for TCL elementary blocks.
Only TCL script actions are supported (i.e. not bridged actions).

By default, the tcsh command which is found along your PATH setting is used (i.e. the same as found when executing "tcsh" on the command line). Of course, you have to have TCL installed on your machine. If unspecified, the value of the "TCL_SHELL" environment variable (in either an expecco environment in scope or the shell environment) is used.

This setting is not needed if you do not use any TCL elementary blocks.

Go Path

Specify which go interpreter to use for Go language elementary blocks.
Only Go script actions are supported (i.e. not bridged actions).

By default, the go command which is found along your PATH setting is used (i.e. the same as found when executing "go" on the command line). Of course, you have to have go installed on your machine. If unspecified, the value of the "GO_SHELL" environment variable (in either an expecco environment in scope or the shell environment) is used.

This setting is not needed if you do not use any Go elementary blocks.

Gnuplot Path

Specify which gnuplot interpreter to use for Plot/Graph elementary blocks.
Gnuplot actions are script actions (i.e. not bridged actions).

By default, the gnuplot command which is found along your PATH setting is used (i.e. the same as found when executing "gnuplot" on the command line). Of course, you have to have gnuplot installed on your machine. If unspecified, the value of the "GNUPLOT_SHELL" environment variable (in either an expecco environment in scope or the shell environment) is used.

This setting is not needed if you do not use any Plot/Graph elementary blocks.

GnuOctave Path

Specify where to find the gnu "octave" command (a math programming language, similar and mostly compatible to Matlab).
Octave actions are script actions (i.e. not bridged actions).

By default, the octave command which is found along your PATH setting is used (i.e. the same as found when executing "octave" on the command line). Of course, you have to have octave installed on your machine. If unspecified, the value of the "GNUOCTAVE_SHELL" environment variable (in either an expecco environment in scope or the shell environment) is used.

On a Windows machine, octave is typically found at "C:\Program Files\GNU Octave\Octave-6.3.0\mingw64\bin\octave-cli.exe" (your version number likely being different).

This setting is not needed if you do not use any GnuOctave elementary blocks.

Using a "real" Matlab

(this is experimental and as yet untested)

Enter as octave path the path to your matlab executable; eg: F:\Program Files\MATLAB\R2021a\bin\matlab.exe. Verify by pressing the "?" button - it should present something reasonable, such as:

MATLAB Version: 9.10.0.1739362 (R2021a) Update 5
MATLAB License Number: DEMO
Operating System: Microsoft Windows 7 Professional  Version 6.1 (Build 7601: Service Pack 1)
Java Version: Java 1.8.0_202-b08 with Oracle Corporation Java HotSpot(TM) 64-Bit Server VM mixed mode
-----------------------------------------------------------------------------------------------------
MATLAB                                                Version 9.10        (R2021a)
Simulink                                              Version 10.3        (R2021a)

Notice that some functions might behave differently - especially those related to output graphics to a window or file.

'R' Path

Specify which 'R' interpreter to use for RScript elementary blocks.
"R" actions are script actions (i.e. not bridged actions).

By default, the 'R' command which is found along your PATH setting is used (i.e. the same as found when executing "R" on the command line). Of course, you have to have 'R' installed on your machine. Notice, that on OSX and Windows systems, the 'R' command is named 'r' (lowercase), whereas on Linux systems, it is called 'R' (uppercase). If unspecified, the value of the "R_SHELL" environment variable (in either an expecco environment in scope or the shell environment) is used.

This setting is not needed if you do not use any RScript elementary blocks.

External OCR Tools Settings

Expecco uses an external framework for OCR (Optical Character Recognition) to extract text from bitmap images (screen shots) - especially in GUI automation, when local screen or VNC GUIs need to extract text from captured screenshots.

Best results are achieved with OCR frameworks which generate detailed (per word) bounding box information (i.e. in hOCR format, as specified in http://kba.cloud/hocr-spec/1.2).

Supported OCR Frameworks

Tesseract

At the moment, the most powerful free framework is the "tesseract" open source program, which can be downloaded and installed from https://github.com/tesseract-ocr/tessdoc (source), binaries for Windows and OS X are found in https://github.com/UB-Mannheim/tesseract/wiki.
Make sure to also download and install language packs (eng, deu, etc.), which should be unpacked in "C:\Program Files\Tesseract-OCR\tessdata" (typically).
Tesseract generates hOCR output.
Tesseract is available for Windows, Linux and OSX.

Capture2text

For Windows, another popular package (which is also based on tesseract) is "capture2text", which can be downloaded and installed from https://sourceforge.net/projects/capture2text.
Capture2text does not generate hOCR output.

GNU Ocrad

A free command line OCR tool which can be downloaded from https://www.gnu.org/software/ocrad.
The software must be downloaded as source and compiled with "configure"followed by "make install".
Be aware that ocrad's quality of recognition is poor compared to tesseract, and that ocrad does not generate hOCR output.

Other

You may also use any other (possibly commercial) OCR framework.

Settings

In the OCR settings dialog, first choose the framework to use (i.e. tesseract, capture2Text or other), then the path to the corresponding OCR command itself (eg. "c:\program files\Tesseract-OCR\bin\tesseract.exe" or simply "tesseract", if it is in your path). Finally a number of command templates, which are expanded with command-path, input file Name (png) and output file Name (txt). If the command needs any extra command line arguments, define them in the templates.

If supported by the OCR command, separate templates should be provided to extract digits only (for numeric data) and to provide a language hint.

For tesseract and capture2text:
Please make sure that the language specific tessdata packages are installed (files are typically in "c:\program files\Tesseract-OCR\tessdata" or "/opt/local/share/tessdata" on Unix systems).
If not, download from: https://github.com/tesseract-ocr/tessdata_best.

See Also

Installing additional frameworks

---

Copyright © 2014-2024 eXept Software AG