[Feature Request]: Eliminate the false "stuck script feeling"

[ahmednasr95]

Problem Description

While using the validations assertThat and verifyThat, it came to my attention that while the script is validating, I had the "feeling" that the script is stuck or not working as expected. However, when I waited for the timeout period , which is 60 seconds as default, the script continued and finished successfully.

I guess that it would be better to show the user that the script is actually waiting to eliminate the "feeling" of the script being stuck.

Moreover, when the actual value of the assertion is true and the expected is false, the console continues to output the following message for the total waiting time: `[INFO] Expected "false", and actual "true" | com.shaft.tools.io.ReportManager - main - 06:16:44 PM ' as shown in the attached screenshot.

Solution Description

I guess it would be better to make the console output one of the following during the waiting time just to show that the console is waiting and to eliminate the "stuck script feeling":

• A series of dots that increase after 10 seconds of the waiting time elapsed
• A progress bar that fills up after 10 seconds of the waiting time elapsed
• A simple message that indicates that the driver is waiting for amount number of seconds

Additional context

[AhmdZanoon]

Dear @ahmednasr95 are you testing normal application or company application behind vpn or proxy

[AhmdZanoon]

@ahmednasr95 another note that the provided screenshot related to another issue currently under investigation, i guess the stuck issue you mean is faced also when assertion pass or only in case of failing

[AhmdZanoon]

@ahmednasr95 another note that the provided screenshot related to another issue currently under investigation, i guess the issue you mean is faced also when assertion pass or only in case of failing

[ahmednasr95]

• first note: normal application
• Second Note: Yes, it also occurs when the assertion pass, but in the pass case, nothing is displayed in the console during the waiting period thus raising the aforementioned concern.

[AhmdZanoon]

Kindly share piece of code you use or and your custom properties file if exist

[ahmednasr95]

@zanoon2020 Yes, of course. The following code snippet is the one that causes the problem.

driver.assertThat().element(emailExistsErrorMessage).doesNotExist().perform();

In the code above, the emailExistsErrorMessage element is located successfully, thus it exists. This makes the actual result to be false therefore failing the assertion.

I also identified the root cause of the problem. In the following snippet in the validateElimentExists method, the validation state returns with false because the actual and expected values are not equal, therefore; the fluentWait will keep on counting till it reaches the timeout.

            new SynchronizationManager(driver).fluentWait(false).until(f -> {
                elementCount.set(new ElementActions(driver, true).getElementsCount(locator));
                expected.set(validation.getValue());
                actual.set(elementCount.get() > 0);
                // force validation type to be positive since the expected and actual values have been adjusted already
                validationState.set(performValidation(expected.get(), actual.get(), ValidationEnums.ValidationComparisonType.EQUALS, ValidationEnums.ValidationType.POSITIVE));
                return validationState.get();

Furthermore, the performValidation method calls the compareTwoObjects method to validate the assertion which happens to start by logging to the console through the following statement.

ReportManager.logDiscrete("Expected \"" + expectedValue + "\", and actual \"" + actualValue + "\"")

Since the the lambda function in the until method will keep on executing till either it returns true, which it won't, or a timeout exception is raised, compareTwoObjects will be executed each tick, which is by default 100 ms, and therefore will log into the console thus creating the issue stated before.

Therefore, I suggest the following:

• Remove the logging from the compareTwoObjects method and add it before executing the fluent wait. (if possible)
• Add a progress bar that fills up based on the time elapsed which will help in showing that the script is running.
• Add the bar to all waits because when an element is waiting to be located, nothing is shown in the console as contrary to the normal flow of the script which in turn will induce the "stuck script feeling" as mentioned earlier.

Note that I would like to contribute to solving this issue and I already created the progress bar code but need help in merging it with SHAFT.

The following is a short video showing the idea of the progress bar.

https://github.com/ShaftHQ/SHAFT_ENGINE/assets/37153097/0b3f9ef8-008a-4bd0-9d56-5e68cc3f5005

[AhmdZanoon]

Dear @ahmednasr95 , this is the expected behavior for notExist , you are telling the engine to assert that an element not there so the engine waits the full timeout duration defined in the properties. To know the difference please try again with assert().exist , you will not phase this .

If you don't need notExist to wait all duration You can change the timeout duration just before the assert statement and return it to the original value after the assert statement

[AhmdZanoon]

And as i told you the issue of logging every 100 ms second is under investigation,

For the idea of progress bar let us discuss it more with our technical committee @MohabMohie @MahmoudElSharkawy @MustafaAgamy

[MohabMohie]

I like the progress bar idea. And you seem to know already what you want to change. Would you kindly do a PR with your suggested changes? Do you need any help?

[ahmednasr95]

@MohabMohie Yes, in order to do a PR I need a branch to work on or should I fork?

[MahmoudElSharkawy]

You need to fork and create a new brach