Feature/control api delay

[TobiasAdler]

Description

This PR adds a new method withDelayAfterAction to CONTROL api to provide a possibility to define a delay after actions on specific elements are performed.

Example of usage:

CONTROL.withDelayAfterAction(1, () -> {
    button.click(); // Delay of 1 second after the click
});

Type of change

• [ ] New feature (non-breaking change which adds functionality)
• [ ] This change requires a documentation update

Checklist:

• [ ] My code follows the style guidelines of this project
• [ ] I have performed a self-review of my own code
• [ ] I have commented my code, particularly in hard-to-understand areas
• [ ] I have made corresponding changes to the documentation
• [ ] My changes generate no new warnings
• [ ] I have added tests that prove my fix is effective or that my feature works
• [ ] New and existing tests pass locally with my changes
• [ ] Any dependent changes have been merged and published in downstream modules

[mreiche]

I prefer a overloaded method withTimeout like:

CONTROL.withTimeout(int seconds, int delayAfterAction, () -> {
    element.expect().text("Hello World");
}

[martingrossmann]

I prefer a overloaded method withTimeout like:

CONTROL.withTimeout(int seconds, int delayAfterAction, () -> {
    element.expect().text("Hello World");
}

But using this method you must setup a new timeout. From my point there is no direct relation between a uielement timeout and a delay.

[mreiche]

What about something like:

CONTROL.with(new Override().timeout(3).delayAfterAction(300).retryCount(5), () -> {
    element.expect().text("Hello World");
}

[martingrossmann]

To be consequent I prefer to add an additional method for CONTROL. But we should change milliseconds to seconds, because all other methods using seconds.

[mreiche]

I don't like the Idea, of having these "internal timeouts" as regular high level API feature. The properties UiElement.ELEMENT_WAIT_INTERVAL_MS or UiElement.DELAY_AFTER_ACTION_MILLIS are internal timeouts for not spamming the WebDriver API in case of failures and give the Browser some rendering time. Thats why it is defined in milliseconds per default and they should fit usually for most use-cases.

For particular use-cases (I don't know which they are), you can always use property overriding like:

PROPERTY_MANAGER.setTestLocalProperty(UiElement.DELAY_AFTER_ACTION_MILLIS, 200);
// your test code here

[martingrossmann]

The idea was to slow down the execution for a defined number of steps, not for the whole testcase. Maybe the origin usecase was to specific for a project.

I agree that a user API should not update properties which are intended for internal use only.

[mreiche]

Slowing down the execution is a bad practice when the reason is to outplay flaky DOM elements. It is better to check for the state change in the DOM after every action.

[martingrossmann]

Slowing down the execution is a bad practice when the reason is to outplay flaky DOM elements. It is better to check for the state change in the DOM after every action.

Yes, thats true. I close this PR without merge.