Maestro 不稳定性：源代码分析

Source: Dev.to

Maestro 将自己定位为一个“拥抱移动应用不稳定性”的测试框架。
但这在代码中到底意味着什么呢？我深入源码进行探究。

市场承诺

来自 Maestro 文档：

“UI 元素并不总是出现在你预期的位置，屏幕点击也不一定总能成功，等等。Maestro 接受移动应用和设备的不稳定性，并尝试加以应对。”
“无需在测试中到处使用 sleep() 调用。Maestro 知道加载内容可能需要时间，并会自动等待（但不会等待超过必要的时间）。”

听起来很棒。让我们看看代码实际做了什么。

1. 元素查找 – 硬编码的 17 秒超时

当你写 tapOn: "Login" 时，Maestro 并不是查一次就失败。它会持续轮询。但会轮询多久？

Source: Orchestra.kt

class Orchestra(
    private val maestro: Maestro,
    private val lookupTimeoutMs: Long = 17000L,        // Hardcoded: 17 seconds
    private val optionalLookupTimeoutMs: Long = 7000L // Hardcoded: 7 seconds for optional
)

这意味着什么

• 每次元素查找默认最多等待 17 秒。
• 可选元素等待 7 秒。
• 你 无法 为单个命令更改此超时。

想为慢速 API 响应等待 30 秒？抱歉不行。想在性能测试中 3 秒内快速失败？同样不行。

2. 轮询机制 – 简单但僵硬

Source: MaestroTimer.kt

fun  withTimeout(timeoutMs: Long, block: () -> T?): T? {
    val endTime = System.currentTimeMillis() + timeoutMs

    do {
        val result = block()
        if (result != null) {
            return result
        }
    } while (System.currentTimeMillis()

注意： 最大等待时间为 10 秒（10 次轮询 × 1 秒）。此值 不可配置。

7. 平台差异：Android 与 iOS

Maestro 在不同平台上对“settling”进行不同处理。

Android

Source: AndroidDriver.kt

// Checks if window is still updating
val windowUpdating = blockingStubWithTimeout.isWindowUpdating(...)

iOS

Source: IOSDriver.kt

// Uses screenshot comparison to detect animation end
val didFinishOnTime = waitUntilScreenIsStatic(SCREEN_SETTLE_TIMEOUT_MS)

两种方法的可靠性特征不同，但 都不提供可配置性。

概述：硬编码的现实

判决

Maestro 的“内置不稳定性处理”比原始的 XCUITest 或 Espresso 更强大，但它是一个 硬编码值的一刀切解决方案。

• 代码简洁，方法可靠。
• 缺乏后备方案意味着当默认设置不适用于你的应用时，你会陷入困境。

这并不一定是坏事——这是为简化而做出的权衡。然而，营销宣传暗示的智能性和适应性比代码实际提供的要多。

关键源文件

我们不只是指出问题

我们喜欢 Maestro 的 YAML 语法——它可以说是近年来移动测试自动化领域最好的创新：简洁、易读且便于版本控制。

但执行引擎确实存在一些限制：

• 硬编码的超时
• 无法配置
• 平台不一致

所以我们正在构建一个解决方案。

一个开源引擎，在 Appium 经过实战检验的基础设施上运行 Maestro YAML 测试，提供：

• 可配置的超时
• 真机支持
• 没有魔法数字

敬请期待。

Learn More