slow pressKey

[farfromrefug]

I have a flow like this:

- clearState
- launchApp
- inputText: 654208
- extendedWaitUntil:
    visible: 
        id: "loading"
    timeout: 5000
- extendedWaitUntil:
    visible: 
        id: "toto"
    timeout: 10000
- pressKey: Enter
- extendedWaitUntil:
    visible: 
        id: "loading"
    timeout: 5000
- extendedWaitUntil:
    notVisible: 
        id: "loading"
    timeout: 5000
- pressKey: back
- pressKey: Remote Dpad Down
- pressKey: Remote Dpad Down
- pressKey: Remote Dpad Down
- pressKey: Remote Dpad Down
- pressKey: Enter

The beginning works great but when coming to the pressKey events, it waits ~10s between each pressKey. Can i disable this?

[Fishbowler]

Short version: No

Long version: Having peeked at the code in the project for this, here's a rough guide on what's happening when you run pressKey:

• Key event is emitted to the device, and Maestro waits 0.3s for that to take effect
• The pressKey command calls another function before returning, which is waitForAppToSettle, which as you can guess from the name is a function intended to ensure that the effect of the action has finished before progressing to the next step. This function successively checks the hierarchy, until either it's checked 10x, or it returns the same hierarchy 2x in a row. There's a 0.2s wait after each check of the hierarchy after the 2nd one.

I suggest checking to see if there's animation happening on the screen when pressKey is occuring, and if there are, suppressing those during test execution by both:

• Disabling animations in the settings of the emulator
• Using launch arguments to detect when you're under test and turning off those specific animations

[farfromrefug]

@Fishbowler thanks a lot for your detailed answer. Couldnt we get parameters to pressKey to configure (or even disable) that waitForAppToSettle?

if this not something you intend to do. Is there a way to create custom "commands" for maestro? That way i could create a custom one which pressKey without so much delay

disabling animations is not really something i want because then the behavior of the app does not reflect what would happen in real life

[Fishbowler]

I'd have no objections to a PR that added the same waitToSettleTimeoutMs that exists on tapOn to other commands like pressKey.

Previously I said

This function successively checks the hierarchy, until either it's checked 10x, or it returns the same hierarchy 2x in a row.

That's an oversimplification. In tapOn, the waitToSettleTimeoutMs is passed to the function, and where a timeout is passed, the loop continues until the timeout is exceeded rather than 10x. That sounds pretty apt for your situation.

[Fishbowler]

Slightly off-topic. This about to get nerdy soapboxy on testing theory.

On your point about disabling animations being unrepresentative, I'd offer: if the animations aren't being tested, are they really part of the scenario under test?

Consider that all state management in e2e tests is an illusion, since we're dealing with tests of complex systems on top of complex operating systems. Arrange, Act, Assert is something we strive for but never reach (your test runs fine 99x out of 100, but you still get the occassional app crash through an OS bug, or a selector that fails due to an OS popup). As such, we get our confidence through both breadth and depth of testing. You can optimise here for functional testability, giving you your functional flows the ability to progress at pace. Elsewhere, human eyes or some other tool performs some validation that the animation is doing what it should.

[farfromrefug]

Not sure about creating a PR yet. There are a few pieces in that repo, and i am not sure of all the places i should modify.
Looking at the code i saw that though

Maestro/maestro-client/src/main/java/maestro/Maestro.kt

Line 402 in 2c82177

fun pressKey(code: KeyCode, waitForAppToSettle: Boolean = true) {

. There is already a waitForAppToSettle parameter but i dont think it is plugged anywhere. Would be nice to have this one at least. Then waitToSettleTimeoutMs would a nice additional parameter