[MGNLCE-86] UI Test improvements as preparation for using docker and chrome Created: 13/Jul/17  Updated: 07/Sep/17  Resolved: 04/Sep/17

Status: Closed
Project: Community Edition
Component/s: None
Affects Version/s: None
Fix Version/s: 5.5.7, 5.6

Type: Task Priority: Neutral
Reporter: Michael Mühlebach Assignee: Michael Mühlebach
Resolution: Fixed Votes: 0
Labels: None
Σ Remaining Estimate: Not Specified Remaining Estimate: Not Specified
Σ Time Spent: Not Specified Time Spent: Not Specified
Σ Original Estimate: Not Specified Original Estimate: Not Specified

Issue Links:
Relates
relates to MGNLCE-85 Introduce new selenium test setup wit... Closed
relates to MGNLEE-500 Adapt to changes from MGNLCE-86 Closed
supersession
Sub-Tasks:
Key
Summary
Type
Status
Assignee
MGNLCE-87 Use consequently waitUntils in dynami... Sub-task Closed Michael Mühlebach  
MGNLCE-89 Fix incorrect usage of Selenium impli... Sub-task Closed Michael Mühlebach  
MGNLCE-88 Incorrect usage of appIsLoaded() cond... Sub-task Closed Michael Mühlebach  
Template:
Acceptance criteria:
Empty
Task DoR:
Empty
Epic Link: Improve QA setup
Sprint: Basel 106, Basel 107, Basel 108, Basel 109, Basel 110, Basel 111, Basel 112
Story Points: 13

 Description   

The improvements consist of the following main parts:

Use FluentWait instead of just assertions (MGNLCE-87)

Because a lot of the interaction are dynamic, meaning they are done via JavaScript without HTTP Request/Response, Selenium has little knowledge when the DOM is ready for queries, clicks or assertions.
For those situations we should use FluentWait with our convenience methods waitUntil and assertEventually. There we have the possibility to describe the status we expect to reach, like the status indicator after a publication to turn green, as a condition and the selenium framework evaluates it periodically until met.

Rely on explicit instead of implicit waits (MGNLCE-89)

Selenium FluentWaits are considered explicit waits because we declare a condition we are looking for, for a certain amount of time which could be individually configured. Selenium provides another way to wait for elements in the DOM with implicit waits which are used globally. That wait or timeout is used whenever the DOM is queried for an element by the driver.
Implicit waits do not ideally work in more complex situation because they work when querying the DOM tree and not when waiting for derived attributes like displayed or combinations of conditions. This is why we have FluentWaits.
Because implicit and explicit timeouts influence each other (see MGNLCE-89 for more details) they should not be used simultaneously.

Incorrect use of appIsLoaded() condition (MGNLCE-88)

We used the condition appIsLoaded() as general wait if something is happening condition. This worked ... but only by accident. The condition was implemented incorrect for most situations but instead of failing it turned into a delay(10). Because this is quite expensive in the end we have to use appropriate conditions instead of appIsLoaded()

Other smaller changes

There are other small changes ... best have a look at the PR.
Most notable is probably the use of a correct log4j.xml which directs all log messages during the tests into a log file. JUnit and Selenium messages are still displayed as expected.


Generated at Mon Feb 12 00:06:09 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.