Settings

Settings

Speed optimizations

  • Timeouts and Delays: Each page exhibits unique behavior, especially in terms of the speed at which elements become visible. The dropdowns are designed to minimize the need for explicit waits within the test case scripts.
  • Performance: These settings prioritize testRigor’s behavioral approaches over the user’s UI interactions. All of them influence the test case duration, and as a result, the overall run time. The “Getting visibility of elements approach” option is particularly significant. In batched mode, testRigor can detect any element loaded in the DOM, regardless of its visibility on the screen. Conversely, the visible-first mode restricts interactions to elements that are both visible and contained within the viewport.

Advanced section

The “Advanced” section houses settings for processing newly opened tabs, iframe depth, and other options. We offer checkboxes for enabling synonyms. With this feature, testRigor identifies words with similar meanings, ensuring that minor word changes on pages won’t necessitate script alterations. Additionally, we support custom attributes: if there’s an HTML tag we don’t recognize by default, users can assign that tag to aid element detection. Users can also specify custom cookies to inject into a page before a test begins. This is beneficial for scenarios such as setting a language on multilingual sites or ensuring that users are logged in at the test’s start.

Synonyms

Here’s how you can use synonyms to self-heal test cases when terminology on your page has slightly changed:

  • A message will be shown in Extra info below the screenshot if an element was found by a synonym in the test case. For example:
    • Element ‘Well’ found by synonym ‘good’
  • We created an option to enable/disable it in Settings -> Advanced -> Search for synonyms if an element is not found. This option is enabled by default for new test suites.
  • Suites created before the release of this feature have this option disabled to avoid changing the behavior of existing test cases.

Furthermore, users have the option to specify the name of their site-wide loading spinner, allowing our system to automatically pause and wait until the spinner disappears before interacting with the page. The Advanced settings also define our interactions with PDFs (to either download or view them), with clicks (determining if the default action should be via JavaScript or a mouse click), and with monitoring.

For example, you can allow/disable parallel testing for the suite in Advanced settings->Speed optimizations->Allow parallel testing. Another example is that you can check that CSS files have been loaded on the page through Error reporting under Advanced settings.

Test your knowledge

Enable sequential mode in test settings.
Adjust the speed settings to the slowest mode.
Modify the test script to add delays between each test case.
Disable parallel testing for the suite in Settings->Speed Optimizations->Allow parallel testing.
Run the test suite multiple times to ensure they don’t overlap.

Manually inspect the page source for CSS links.
Navigate to error reporting under settings > check that CSS files loaded successfully.
Check the browser’s console for any missing CSS file errors.
Utilize a third-party CSS validator.
Monitor the network tab in the browser’s developer tools for any failed CSS requests.

[wpcode id=”1112380″ answers=”4;2″ page=”Settings” numoffields=”2″]