[Feature_Request] Support optional flag with extendedWaitUntil & visible/notVisible with timeouts

[manjususan11]

Requirement : Right now there is not action to force wait the app on a fixed time of duration , if we can support "optional" flag with

extendedWaitUntil: notVisible/visible: optional: timeout: we can achieve the force wait in larger performance related test cases (e.g keeping app for longer duration of time and cross check for memory leaks )

[manjususan11]

@axelniklasson hey , had to close the previous issue as I used wrong account to log it, and to your question , Yes it is similar to sleep command or a forced delay

[axelniklasson]

Got it @manjususan11, thanks for the context. As we outline in our docs, we highly discourage the pattern of introducing artifical waits in your application. Could you elaborate a bit more on your use case and why you need the optional flag?

[manjususan11]

@axelniklasson Sure, my requirement is to run my navigation app for a larger duration with some condition in backend which helps in identifying memory leaks if any , unfortunately while it is routing I won't be getting any new UI element or disappear any existing element so can't use any assert visible or notVisible much here , but if I have a sleep feature(OR optional assertVisible/notVisible with a timeout ) I can ask the test to wait for some minutes and then stop test successfully but I need some screenshots in between(may be every 20 mins )

I hope it is clear :)

[axelniklasson]

Got it, I see your use case. We are quite hesitant to introduce artifical waits that are not depending on UI changes as it will most likely be overused and hide UX issues, so I would recommend trying another approach to do what you want. Maybe you could use maestro to interact with your app all the way to the video recording and then hand off to another process to check for memory leaks?

[arancauchi]

I also would like an extended wait for tests. Sometimes you really do want an escape hatch to wait an arbitrary time for something to update, and sometimes redesigning features isn't always an option.

Adding a warning to the command usage in the cli output could be useful.

All major testing frameworks allow artificial waits (with warnings), and it's something that when used with caution can be very useful.

[venkat2789]

Not meaning to deviate from this issue, but I had a similar request in the past and I have explained my use case here: https://github.com/mobile-dev-inc/maestro/issues/684 @axelniklasson

[venkat2789]

@manjususan11 in case you haven't figured it out yet, this is now possible:

- extendedWaitUntil:
      visible:
        text: "Test"
        optional: true
      timeout: 10000

[andreacab2]

Thanks for the awesome lib!

We have the same need but our situation is different and I believe its genuine and maybe more mainstream. I say this because in our situation we use BLE and a button to write data to some peripheral and when you do some robotics or IOT things are not always completely connected or strongly consistent. The writing of the data triggers a small servo motor that takes time to finish its job. Our button is used to trigger the servo motor but goes inactive and becomes active straight away when the signal is received and not when the motor finishes its job. It would have been useful for us to let the script know that it needs to wait for some amount of time before moving further.

Of course, we could poll the status of that servo motor to make it fit with the maestro framework but I think from a UX perspective it would be wrong in our situation. We prefer to give the control to the user and let him see physically if the job is done or not and up to him to re-click the button if needed, instead of trying to be smart and make the button reflect the motor status. Anyway, just adding my bits here maybe it's not that genuine..