... | ... | @@ -52,18 +52,18 @@ We start off by creating our test class. |
|
|
self.driver.quit()
|
|
|
```
|
|
|
|
|
|
We'll also define some boilerplate setup logic. This will start the app org.kde.kcalc.desktop through its desktop file. You can also pass command lines to instead fork a process manually. For example you might start a Plasma applet with `"plasmawindowed org.kde.plasma.calculator"`. Valid app options are:
|
|
|
We'll also define some boilerplate setup logic. This will start the app org.kde.kcalc.desktop through its desktop file, and expect that it correctly set its desktop file id on the window as well - when not dealing with a proper GUI app you may want to use another startup method: You can also pass command lines to instead fork a process manually. For example you might start a Plasma applet with `"plasmawindowed org.kde.plasma.calculator"`. Valid app startup options are:
|
|
|
|
|
|
- desktop file id: `desired_caps["app"] = "org.kde.kcalc.desktop"`
|
|
|
- command line: `desired_caps["app"] = "plasmawindowed org.kde.plasma.calculator"`
|
|
|
- pid: `desired_caps["app"] = "12356"` please note that you are in charge of ensuring that this pid actually terminates properly once your test is done!
|
|
|
- desktop file id: `desired_caps["app"] = "org.kde.kcalc.desktop"` the app will be started by its desktop file name similar to how plasma would start it
|
|
|
- command line: `desired_caps["app"] = "plasmawindowed org.kde.plasma.calculator"` the app will be fork()ed off without any expectation of having desktop file ids available
|
|
|
- pid: `desired_caps["app"] = "12356"` you are in charge of starting the app and pass the pid in. please note that you are in charge of ensuring that this pid actually terminates properly once your test is done!
|
|
|
|
|
|
Let's write our first test. A simple addition should do. To write selenium tests we need to tell the driver to find specific UI elements and interact with them (e.g. click them). There are a number of options for finding elements based on at-spi properties:
|
|
|
|
|
|
- name: `self.driver.find_element(by=AppiumBy.NAME, value="AC")`
|
|
|
- description: `self.driver.find_element(by='description', value="Result Display")`
|
|
|
- class name: `self.driver.find_element(by=AppiumBy.CLASS_NAME, value="[push button | AC]")`
|
|
|
- accessibility id: `self.driver.find_element(by=AppiumBy.ACCESSIBILITY_ID, value="QGuiApplication.QQuickWindow_QML_28.developerPage")` the ID is constructed from objectNames and the object tree. The id is matched from the end (e.g. in the example value="developerPage" would also match)
|
|
|
- accessibility id: `self.driver.find_element(by=AppiumBy.ACCESSIBILITY_ID, value="QGuiApplication.QQuickWindow_QML_28.developerPage")` the ID is constructed from objectNames and the object tree. The id is matched from the end (e.g. in the example value="developerPage" would also match). On the QML side you can also set an objectName when you need to find an Item by its id rather than name or description.
|
|
|
- class name: `self.driver.find_element(by=AppiumBy.CLASS_NAME, value="[push button | AC]")` the class name is comprised of the `type` and `name`, you can easily find this identifier in accerciser's API Browser tab (combobox might need changing away from the "Accessible").
|
|
|
- xpath: `//dialog[@name="Duplicate?"]//push_button[@name="Yes"]` based on an XML representation of the object tree. The xml may be accessed via `http://127.0.0.1:4723/session/$$SESSION-UUID$$/sourceRaw`. http://xpather.com/ is a useful tool to test xpath queries.
|
|
|
|
|
|
To figure out what to actually look for we can look at at-spi directly. To do this we'll use the tool "accerciser". On the left hand side you can navigate the various accessible elements. On the right hand side you can inspect the element. The most pertinent tab here is 'Interface Viewer', it let's us find most of the locator types as well as inspect interaction options we have in the "Action" group as well as state assertion options in the "States" list view.
|
... | ... | |