44

Running an application from QF-Test

NoteThe Setup sequence creation is the recommended tool to set up your SUT for testing. It results in an advanced setup sequence already prepared for later requirements.

This chapter contains some details in case you want to create a setup sequence yourself.

44.1

Various methods to start the SUT

With the Quickstart Wizard QF-Test offers a utility to guide you through the steps of creating a start sequence for your SUT. Please refer to chapter 3 for more information about the Quickstart Wizard.

Nevertheless we also want to describe how to create a start sequence for your application manually. There are basically two ways to start a Java application as an SUT from QF-Test. The first one is based on the standard java ... command line with its two variants for either starting a class or a jar file. The alternative is running a script or executable file which will then start the Java program. Indirect methods like launching the SUT through ant also fall into this category, as do Java WebStart and applets run in the Java plugin of a web browser.

The following examples show some typical setups. To get more detailed information about the required attributes, please follow the respective links to the reference manual. The tutorial also includes a number of examples.

Independent of how the SUT is started, the respective node should typically be followed immediately by a 'Wait for client to connect' node with an identical 'Client' attribute. Again, see the reference manual for further details.

44.1.1

A standalone script or executable file

If your application is started through a script or a binary executable, create a 'Start SUT client' as follows:

		Figure 44.1:  Starting the SUT from a script or executable

• Create a 'Start SUT client' node.
• Assign a name to the client in the 'Client' attribute.
• Set the 'Executable' to the script or executable that starts your application. If the program is not located in a directory on the PATH, the full path is required.
• Set the 'Directory' attribute to the working directory for your application.
• One thing to watch out for in scripts is redirection of the standard output and error streams (e.g. >myapp.log) which you may want to remove so that the output of the SUT reaches QF-Test and is captured in the run log. Similarly, the start command in Windows batch files causes the SUT to detach and keeps the output away from QF-Test.

44.1.2

An application launched through Java WebStart

Using the new connection mechanism, an application launched through Java WebStart can be started directly from QF-Test without the need to modify any JNLP files (so do not use »Extras«-»Create WebStart SUT client starter...«). Instead create a 'Start SUT client' node as follows:

		Figure 44.2:  Starting the SUT through Java WebStart

• Create a 'Start SUT client' node.
• Assign a name to the client in the 'Client' attribute.
• Set the 'Executable' attribute to the Java WebStart executable which is typically called javaws and located somewhere inside the JDK or JRE. You'll probably have to specify the full path.
• For Java WebStart the 'Directory' attribute typically is of no consequence except that Java WebStart is looking in that directory for a file named .javaws which can contain settings like debug levels.
• Create an entry in the 'Executable parameters' for the executable to specify the URL for the application's JNLP descriptor.

44.1.3

An applet in a web browser

Applet testing can be done directly in a browser.

Note In case you own a license that allows web testing with QF-Test and the supported browsers suffice you can also use the "normal" web testing feature (Quickstart your application).

		Figure 44.3:  Starting the SUT as an applet in a web browser

• Create a 'Start SUT client' node.
• Assign a name to the client in the 'Client' attribute.
• Set the 'Executable' attribute to the browser that you want to start, i.e. firefox, iexplore, chrome, safari to name just a few. You may have to specify the full path.
• For starting of an applet, the 'Directory' attribute is of no consequence.
• Create an entry in the 'Executable parameters' for the executable to specify the URL for the applet's web page.

NoteImportant notes on applet testing

Applet testing will only work in a reliable way when

• a new browser process is started,
• no dialogs (like questions on session restore or default browser setting) will block the browser start,
• on Windows 8 the browser is started on the desktop, not as a Modern UI (former Metro) application.

The procedure qfs.web.browser.general.startAsNewProcess that is also used when creating the start sequence with the Setup sequence creation should solve the first two points. It uses browser specific parameters to ensure a new process when possible and avoids blocking dialogs e.g. by using new empty profiles. Please see the procedure documentation for further details.

Further background information

As described above, the qfs.web.browser.general.startAsNewProcess helps to ensure a new process. Hence some hints should be given on some of the techniques used. You can have a look the procedures code as well, of course.

Note Firefox has a built-in session restore feature that causes conflicts with QF-Test. When QF-Test terminates a Java applet and thus the browser, Firefox treats this as a crash and offers to restore the session on the next start through a dialog that cannot be controlled by QF-Test so that the test cannot continue unobserved.

To work around this problem, either always start with an empty new profile or create a separate user profile as described at http://kb.mozillazine.org/Profile_Manager and always start Firefox from QF-Test with this profile using the command firefox -P <profile>. Then disable session restore for this user by editing the preferences as described at http://kb.mozillazine.org/Editing_configuration. You need to add an option called browser.sessionstore.resume_from_crash and set it to false.

44.1.4

An application started with java -jar <archive>

If your application is normally launched through a command of the form java -jar <archive>, create a 'Start Java SUT client' node as follows:

		Figure 44.4:  Starting the SUT from a jar archive

• Create a 'Start Java SUT client' node.
• Assign a name to the client in the 'Client' attribute.
• If necessary, change the 'Executable' attribute. Its default value ${qftest:java} is the java executable that QF-Test was started with.
• Set the 'Directory' attribute to the working directory for your application.
• Create two entries in the 'Executable parameters' table for the executable. Set the first to -jar and the second to the name of the archive. Unless the archive is located in the 'Directory' selected above, its full path is required.

44.1.5

An application started with java -classpath <classpath> <class>

If your application is normally launched through a command of the form java -classpath <classpath> <class>, create a 'Start Java SUT client' node as follows:

		Figure 44.5:  Starting the SUT via the main class

• Create a 'Start Java SUT client' node.
• Assign a name to the client in the 'Client' attribute.
• If necessary, change the 'Executable' attribute. Its default value ${qftest:java} is the java executable that QF-Test was started with.
• Set the 'Directory' attribute to the working directory for your application.
• Set the 'Class name' attribute to the fully qualified name of the application's starter class (the class with the main() method), just like for java.
• Create two entries in the 'Executable parameters' table for the executable. Set the first to -classpath and the second to the list of jar files and directories that constitute the classpath. The full path is required for jar archives not located in the 'Directory' selected above. This argument can get very long and hard to edit directly in the table. See subsection 2.2.5 about how to pop up a dialog for more convenient editing.

Web44.1.6

A web application in a browser

Like Swing, JavaFX or SWT clients, a web-based SUT - i.e. a browser - is started as a separate process from within QF-Test. In order to gain access to the internals of the browser and the web page shown with its Document Object Model (DOM), QF-Test embeds a standard browser like Chrome in a special wrapper application. The technology for embedding and accessing those standard browsers enables efficient access to the DOM beyond the browsers' standard interfaces and a unified interface that hides browser differences and enables QF-Test - and thus you - to focus on test automation with a single set of tests for all supported browsers on multiple platforms.

A 'Start web engine' node can be used to launch a browser.

		Figure 44.6:  Launch the browser process

Browser windows can be opened via a 'Open browser window' node in an already running process.

		Figure 44.7:  Open the web site in the browser

Note When setting up the startup sequence with the Setup sequence creation or defining your own 'Directory of browser installation' attribute, try pointing QF-Test to a current Firefox installation. On Linux, the standard browser for your distribution may be installed in various places.

44.1.7

Opening a PDF Document

4.2+ QF-Test allows to verify PDF documents. Therefore, a client is started as separate process within QF-Test. In order to gain access to the internals of the PDF document and its components QF-Test analyzes the document in its own viewer.

		Figure 44.8:  Opening a PDF Document

A 'Start PDF client' node can be used to launch the viewer and to open the PDF document.

More information can be found in chapter 17.

Last update: 5/31/2023 Copyright © 1999-2023 Quality First Software GmbH