我们喜欢Kakao用于编写UI测试的语法。这个Espresso的包装器使用Kotlin DSL方法，使代码显著缩短并更易读。看看区别：

Espresso:

@Test
fun testFirstFeature() {
    onView(withId(R.id.toFirstFeature))
        .check(ViewAssertions.matches(
               ViewMatchers.withEffectiveVisibility(
                       ViewMatchers.Visibility.VISIBLE)))
    onView(withId(R.id.toFirstFeature)).perform(click())
}

Kakao:

@Test
fun testFirstFeature() {
    mainScreen {
        toFirstFeatureButton {
            isVisible()
            click()
        }
    }
}

我们使用相同的方法开发了我们自己的UI Automator包装器，我们称之为Kautomator。看看下面的代码：

UI Automator:

val instrumentation: Instrumentation = InstrumentationRegistry.getInstrumentation()
val uiDevice = UiDevice.getInstance(instrumentation)
val uiObject = uiDevice.wait(
    Until.findObject(
        By.res(
            "com.kaspersky.kaspresso.sample_kautomator",
            "editText"
        )
    ),
    2_000
)
uiObject.text = "Kaspresso"
assertEquals(uiObject.text, "Kaspresso")

Kautomator:

MainScreen {
    simpleEditText {
        replaceText("Kaspresso")
        hasText("Kaspresso")
    }
}

由于Kakao和Kautomator提供了几乎相同的API，您不必关心测试底层是Espresso还是UI Automator。使用Kaspresso，您可以以相同的风格为两者编写测试。

然而，Kakao和Kautomator本身并不能帮助您看到测试与相应测试用例之间的关系。此外，长测试通常会变成一大段无法拆分成更小部分的代码。 这就是为什么我们创建了一个额外的Kotlin DSL，让您更容易阅读您的测试。

请看下面的示例：

@Test
fun shouldPassOnNoInternetScanTest() =
    beforeTest {
        activityTestRule.launchActivity(null)
        // 一些状态相关的操作
    }.afterTest {
        // 一些状态相关的操作
    }.run {
        step("打开简单界面") {
            MainScreen {
                nextButton {
                    isVisible()
                    click()
                }
            }
        }
        step("点击按钮1并检查按钮2") {
            SimpleScreen {
                button1 {
                    click()
                }
                button2 {
                    isVisible()
                }
            }
        }
        step("点击按钮2并检查编辑框") {
            SimpleScreen {
                button2 {
                    click()
                }
                edit {
                    flakySafely(timeoutMs = 7000) { isVisible() }
                    hasText(R.string.text_edit_text)
                }
            }
        }
        step("检查编辑框的所有可能性") {
            scenario(
                CheckEditScenario()
            )
        }
    }

有时你的UI测试可能连续通过十次,但在第十一次尝试时却因某些神秘原因失败。这被称为不稳定性。

导致不稳定性最常见的原因是UI测试库(如Espresso和UI Automator)本身的不稳定性。为了消除这种不稳定性,Kaspresso使用了DSL封装和拦截器。

让我们观看一个简短的视频,展示了原始UI Automator(右侧)与加速后的版本(左侧)之间的差异。

这里有一个简短的解释,说明了为什么这是可能的。

我们在Kakao/Kautomator拦截器的基础上开发了Kaspresso行为拦截器来捕获失败。

借助拦截器,你可以做很多有用的事情,比如:

• 为每个框架操作添加自定义动作,如写日志或截图;
• 通过重新运行失败的操作、滚动父布局或关闭Android系统对话框来克服不稳定的操作;

以及更多(参见手册)。

Kaspresso会编写自己的日志,详细且易读:

Espresso和UI Automator不允许从测试内部调用ADB命令。为了解决这个问题,我们开发了AdbServer(参见wiki)。

你可以使用Kaspresso类来操作Android系统。

例如,使用Device类,你可以:

• 推送/拉取文件,
• 启用/禁用网络,
• 像用户一样授予权限,
• 模拟电话呼叫,
• 截屏,
• 启用/禁用GPS,
• 设置地理位置,
• 启用/禁用无障碍功能,
• 更改应用语言,
• 收集和解析logcat输出。

(更多信息请参见Device类)。

如果你开发的应用在全球范围内可用,你必须将其本地化为不同的语言。当UI被本地化时,译者看到单词或短语的上下文(即特定屏幕)很重要。

使用Kaspresso,译者可以自动截取任何屏幕的截图。这非常快速,即使对于旧屏幕也是如此,而且你不需要重构或模拟任何东西(参见手册)。

你可以调整Kaspresso的任何部分(阅读更多信息)。

你可以在JVM环境中运行你的UI测试。此外,几乎所有改善稳定性、可读性等的拦截器都将发挥作用。 阅读更多信息。

Kaspresso可以为每个测试生成非常详细的Allure报告: 更多信息可在此处获得。

现在,你可以为Jetpack Compose屏幕编写Kaspresso测试了!DSL和所有原则都是相同的。 因此,你不会看到View屏幕测试和Compose屏幕测试之间的任何差异。 更多信息可在此处获得。