Please find the sample test-suites in the subdirectories demo/carconfigWpf and demo/carconfigForms of the QF-Test installation directory.

Starting the application

The sample test-suites use the dependency SUT_started in the package qfs.autowin.dependencies of the standard library to start the demo application.

The node

  • Execute shell command

actually starts the demo. The

waits for the demo application to appear before passing on control to the test-case itself.

The demo test-suite makes use of the dependency functionality which enables you to manage the set up and clean up requirements of your tests very efficiently. In short, in a test-case the dependency functionality runs the setup node before passing control to the test-case, thus making sure that the requirements implemented in the setup node are met before running the test-case. At the end of the test-case, the cleanup node is not executed by default. Only in the next test-case it may be executed if required by the dependency of that test-case, either because it calls a different dependency or the characteristic variables of the dependency have changed. For more information about dependencies please refer to the tutorial or the manual, chapter Dependency nodes.

For general information on the start of a native windows application please refer to subsection 46.1.1.

GUI element information

The next step after starting the SUT is to get an overview of the GUI elements of the application. In this example we will use the procedure qfs.autowin.helpers.dumpComponents. The output will be written to the QF-Test terminal.

In the following we will have a look at the output of dumpComponents() for some of the GUI elements of the WPF demo application.

Figure 46.2:  The WPF demo application
Window (1)
Name: CarConfiguratorNet WPF
ClassName: Window
ControlType: Window (#50032)

This shows a typical set of identifiers for the window itself. You can address it via its name, which seems to be unique.

Menu (2)
Name: Help
ClassName: MenuItem
ControlType: MenuItem (#50011)
AutomationId: mHelp

This GUI element has an AutomationId. Use this to identify the GUI element unambiguously. Of course, you may also use its name 'Help' or the ControlType (or ClassName) 'MenuItem' along with the index '4'.

Table cell (3)
Name: Rolo
ClassName: DataGridCell
ControlType: Custom (#50025)

The table cell can either be addressed by its name or by the ControlType along with the name. If you want to address the table cell via an index it would make sense to use the ClassName and not the ControlType as the same ControlType 'Custom' is used for non table cells as well. An AutomationId has not been implemented.

Input field (4)
ClassName: TextBox
ControlType: Edit (#50004)
AutomationId: textBoxDiscountPrice

The input field can be addressed via the AutomationId or the ControlType or ClassName along with the index 0.

Text display field (5)
Name: $ 12,300.00
ClassName: Text
ControlType: Text (#50020)
AutomationId: labelCalculatedPriceOutput

Use the AutomationId to identify the GUI element as the name varies according to the text displayed.

Please find general information in subsection 46.1.2.

Performing actions on the GUI elements

In the demo test-suites you will find numerous examples for mouse clicks, checks of texts, values (e.g. in the test-set 'Model prices'), wait for window, text input (e.g. in the test-set 'Options') and the selection of table and list items via index (test-set 'Calculations'). In the following we explain the check of the status of a GUI element as this is somewhat more complex than the actions mentioned before.

Sometimes you cannot determine the properties of a GUI Element by program. In the following we will show you how to check the activation state of the menu item 'Buggy' in the menu 'Help' in a different way.

The job is to check whether the menu item 'Buggy' in the 'Help' menu is ticked.

Figure 46.3:  Help menu

Please have a look at the procedure setBuggy in the package of one of the demo test-suites autowinDemoForms_en.qft or autowinDemoWpf_en.qft.

In order to find out whether the tick mark is set for the menu item or not we resort to an image check. First we need to determine the area on the screen for which to execute the image check. To this end we use the procedure qfs.autoscreen.screen.getGeometry which returns a string containing the values for the x and y coordinates of the top left corner as well as the width and the height of the menu item. We use a script to separate the values and assign them to variables. The actual check whether the menu item 'Buggy' has a tick mark is done via the procedure qfs.autoscreen.screen.getPositionOfImage. We are not interested in the position of the tick mark within the GUI element. However, we are interested in whether it finds it at all. So, depending on whether the procedure finds the tick mark (it throws an exception when the image of the tick mark is not found) and the given state the menu item then is either clicked or left as it is.

We need a file with a reference image of the tick mark for the procedure getPositionOfImage(). One way to create the file with the image of the tick mark as a reference is to take a screenshot, cut out the tick mark and saved it to file. Alternatively you could execute the procedure qfs.autoscreen.screen.getPositionOfImage with an arbitrary image file as input and then navigate to the failed check in the QF-Test run-log. There change to the view 'Got image' and save the image. The advantage is that the image will be cut to the correct size.

Figure 46.4:  Failed Image check in the run-log

You may have noticed that the procedure getPositionOfImage() is run with a parameter algorithm=similarity;expected=0.95. The reason for this is that images tend to differ slighlty on different windows versions. And therefore a check for 100 % identity of the tick mark might fail even though the tick mark showed.