Sakuli V2.3.0 comes with a lot of improvements in performance and stability as well as with a lot of bug fixes and a completely new forwarder integration. Let’s have a look at the major changes for this release.
Besides node 12 support and adjustments in Sakuli click actions, we’ve improved CLI output in case of check/test failures and added ways to ensure a stable website before performing any action. A detailed list of all applied enhancement and fixes can be found in the CHANGELOG.md.
From now on, Sakuli also supports the current LTS version of node (v12.x, codename lts/erbium), so feel free to upgrade your systems to latest LTS.
We updated our enterprise containers accordingly, so starting with 2.3.0 they are now running on lts/erbium.
_click() functionalityA lot of effort went into stabilizing the click functionality on websites.
Clicking a web element might sound trivial at first, but being as heterogenous as it is, the web allows for quite a few edge cases.
Depending on the implementation it might be hard for Sakuli to reliably perform click actions on buttons, links, etc.
Until now, we advised to switch to native desktop interactions in such cases to perform clicks without using the webdriver interface.
For this release, we spent some time on investigating the root cause for these issues. Now Sakuli click actions perform
several technical validations e.g. whether the element to click is visible, before the actual click is performed. If one of
these checks fails, an error will be thrown. On some websites, these strict checks might fail the technical validation.
For those cases, it is still possible to avoid all technical checks and validation by passing the configuration object {force: true} to the click action.
_click(_button("Click Me"), {force: true}); // clicks without validation
Please note that a forced click might lead to false positives, as no validation takes place.
For more information, please have a look at the
_click() API documentation.
We improved the error messages of the CLI output. You will now receive detailed information about syntax errors in test scripts as well as more detailed information on the root cause for errors.
Many modern websites use visual effects regularly. Such effects have impaired test setups in the past. Some users compensated such situations by using _wait() with a fixed timeout. Depending on the system the checks are running on, we have observed that a strict _wait() is not reliable. Therefore we added _pageIsStable() to the
Sakuli API. _pageIsStable() allows you to wait until the DOM of your website has stabilized e.g. after animations are finished or dynamic content has been loaded. As soon as the DOM is stable, test execution continues. It is possible to
configure the maximum timeout to wait and even the intervals in which the DOM is checked.
// Wait for the DOM to stabilize within a maximum 5 seconds and check in an interval of 100 milliseconds.
await _pageIsStable(5000, 100);
For more information, please have a look at the _pageIsStable() API documentation.
With 2.3.0, we have added a Prometheus forwarder to the enterprise forwarder packages. To use the Prometheus forwarder, a valid Sakuli enterprise license is required.
As Sakuli checks are not designed to provide a persistent endpoint for Prometheus to scrape, the forwarder leverages the Prometheus push gateway. For more information about configuration and setup, please have a look at the Prometheus forwarder documentation.
From now on, Sakuli allows to add an optional website URL to the CheckMK spool files. These URLs will be displayed in the CheckMK Web Interface which allows an easy access for the monitoring staff to systems under test in case of an error.
For more information, please have a look at the CheckMK forwarder documentation.
As usual, we updated the container to use the latest Sakuli version, latest security patches and also added node 12 as well as all changes to the
enterprise forwarders. Besides that, we created a completely new container which aims to control remote
Windows machines via RDP. The new image can be found in the enterprise repository on docker hub under
taconsol/sakuli-remote-connection.
To be able to use the new taconsol/sakuli-remote-connection image, a valid Sakuli enterprise licence of
L level or higher is required.