Ecco OpenOffice.org 3.0
Trinity Pullam
expecco can be started manually via the command line, by batch or shell scripts or automatically via the crontab (Unix) or scheduled tasks / services (Windows) mechanism of the operating system. Thus, you can have tests to execute unattended and without GUI "overnight". This is also the method to integrate expecco with other quality tools, such as Jenkins, HP-Quality Center, Polarion, expecco ALM etc.
In addition to the above, expecco can also be started in a slave mode as a service, to wait for incoming test-run request from a QM system, such as expecco ALM or Polarion. Expecco can respond to request via SOAP or REST calls to load, execute and report test suites. The expeccoNET automation environment assumes that expecco is already running on each slave host, and each has been started with a "--server" command line argument. It uses HTTP+SOAP/REST to communicate with those expecco slaves by default.
In this later "slave mode", expecco is installed to run as a daemon process (under Unix) or as a service (under Windows), and will be automatically started by the operating system, when it boots. The details of how it is installed vary between operating systems: under Unix, it needs to be registered in the init-tab-folder, under Windows it needs to be installed as a Windows service.
The return value is useful if expecco is started via a makefile, or from Jenkins, for example.
If the caller needs a different exit code, use one of the "--exitCodeOnXXX" options as described below.This is useful to avoid that a make or jenkins job interprets this exit code as "expecco malfunction" and stops execution.
Command line options are handled at two places: the runtime system (Smalltalk/X VM) and the expecco application itself.When expecco is started, the VM is first to look for command line arguments and processes any of the VM options, untila non-VM option is encountered. It passes the remaining options to expecco's main entry.Thus, any option which is given after the first non-VM option will not be handled by the VM, but by expecco. Therefore, no VM options should be placed after the first non-VM option. VM options are marked as "VM option" in the list below.
this is also the way expecco is started, when a test suite file is double-clicked on the Linux or Windows desktop, or when a test-suite document is dropped onto the expecco icon.The above opens the expecco GUI and loads the given test suite initially. However, it does not automatically execute any test.
You will notice, that expecco shows a banner initially; this can be disabled with a --noBanner option. Also, under Windows, a small tray icon is shown in the lower right, which provides a controlling UI. This is disabled with --noTray.
with this command line, expecco first executes the toplevel testplan(s) from "suiteFile1.ets", then those from "suiteFile2.ets". All parameters (i.e. top-level variable values) will be taken from within the corresponding suite file.
As described below, expecco can generate result files in various formats and different detail. The pdf, HTML and JUnit outputs will contain summary information to be read by humans, archived or to be passed to other programs (e.g. to Jenkins for statistics).
Typically, this kind of composition is used when expecco is called from a QA system, such as Polarion or HP Quality Center, where individual "test sets" are composed out of a collection of existing test cases.
Parameter files in either format can be created manually in a text editor, provided by a QM system (such as expecco ALM, HP Quality Center or similar), generated by another controlling program or generated by expecco itself via the "Save-Parameter" menu function of the environment editor.
Be reminded that the following reports are condensed reports, which only contain a subset of the information contained in expecco's native ".elf" file format. The "elf" file contains all of the execution, trace and data-flow information and the original suite as executed. "elf"-files can be reloaded at any time into the expecco UI and the test be reexecuted. Also, any of the other reports can be regenerated, possibly with different report options (i.e. detail).
In any case expecco has to be started by the jenkins slave. To ensure expecco gets a license, start expecco manually with the same user account as you use for the jenkins slave. expecco will showup the license dialog and you can configure the license to be used. The license configuration will be stored for this user account. As long as the jenkins slave runs under the same user account, expecco gets the same license. If it is not possible to start expecco manually under the same user account as used for the jenkins slave, you can configure the license via command line parameters:
That's it! Because expecco has been told to generate JUnit compatible report files, we can use Jenkins' existing JUnit support. However, the JUnit XML format does not support the full range of information which is present in the native expecco result files (especially the activity log and pin value information is not included).
You can also install expecco slaves inside docker images and run them in the local network or in a cloud. However, if your suite needs access to special hardware, you will need a bridge (and communication tunnel) which provides access to it.
Expecco ALM will ask the expecco slaves about their operating system environment. So jobs will be automatically executed on matching CPU/OS machines. However, if tests require special resources (devices) to be attached, these must be defined and listed in expecco ALM as well. If your test has corresponding resource-requirements defined (see resources/inventory), expecco ALM will both ensure that the test will execute on the correct machine, and also reserve the resource during the execution.
For this, expecco should be started on the test host(s) in so called "slave" mode.In this mode, expecco awaits for execution commands via SOAP or REST, executes tests in the background and returns status information (progress) and results (reports).
Expecco stores testsuites in a file with '.ets' extension (which stands for: "Expecco-Test-Suite") and result logs in '.elf' files (stands for: "Expecco-Log-File").These are technically zip files - i.e. a bundle of individual files which can be extracted with the common zip command line tool (winzip under Windows systems, zip/unzip under Unix systems).
Notice, that you have to be careful when ets-files are bundled with zip manually: for various consistency checks, expecco generates a validation signature of the components and saves this as an additional file inside the .ets file.This signature file must be preserved and it must be consistent with the other zip-components. In effect, this means that an ets can only be constructed from the very same components, using the very same signature file as were extracted before. Otherwise, expecco refuses to load the ".ets" file later.
Unless a QA system like "expecco ALM" is used, ets-files can be stored and maintained in any other source code management (SCM) system, for example, CVS, SVN, hg/Mercurial, git, Perforce etc.Make sure to store the .ets as binary file, and/or disable source expansion of version tag lines (for example, "$Header" or "$Id" in CVS). Consult your particular SCM system's documentation on how this is done.
For example, in the SVN system, an external diff tool can be defined. You could write a little shell or batch script, which calls expecco with the "--diff" option which is described above. Thus, you would get meaningful diff output even from checked in ets-bundle files. The output can then be used as a checkin "log" message.
Your checkin script can also be written to first check if there are differences and then open a diff-viewer with the "--vdiff" command line option. The diff-viewer is the same as opened via the "Compare against Version in File" menu command found in expecco.
Expecco can be scripted either by reading a script from a file or remote controlled via a telnet like command-line interface.This is useful to execute complex test scenarios and meta tasks, to create or manipulate test suites automatically and for self-testing expecco by using another expecco to control its GUI.It can also be used to execute and automate more complex scenarios without using expecco ALM.
Example uses are:
A few objects are predefined by name; among them are "expecco", which refers to the browser itself (i.e. the UI) and "environment", which refers to a collection of variable bindings (this is a dictionary of interpreter variables - not to be confused with a variable environment as known inside an expecco activity block).
New variables can be defined with a "var ;" statement.
For example:
Environment objects are used to store key-value bindings for expecco variables. Environments form a hierarchy, where values are searched for in an environment's parent environment, if not present. This hierarchy follows the containing compound activity chain up to the project (= test suite) environment.Additional temporary environments are kept by the executor and the browser, to keep temporary values for a single execution's or a single session's lifetime.
Especially the RPC mechanisms are useful to integrate expecco into the company test infrastructure.Such interfaces are meant for programmatic control of an expecco slave from quality management, application life cycle and other scheduling tools.Our own companion product, expecco ALM and third party tools, such as Polarion use these service interfaces.
The service interfaces are useful to control unmonitored slave machines in the network, among which expecco test execution jobs are scheduled by another program. Expecco ALM and other quality management tools use these to initiate test runs in a test server farm.For this, the basic operations "download of a suite", "execute a suite" and "requesting execution results" are available as service calls.
aa06259810