1

由于 EarlGrey 在该过程中运行，并且没有像 XCUI 测试框架中那样涉及安装/卸载过程，我希望测试运行得更快，但我注意到它与 XCUI 测试框架的速度几乎相同。有什么理由吗？

获取 TabBar 或 NavBar 项目非常慢。我怎样才能加快这个过程？

我正在使用它来匹配 TabBar 元素

let tabButtonMatcher: GREYMatcher = grey_allOf([grey_accessibilityLabel("Something"), grey_accessibilityTrait(UIAccessibilityTraitButton),  grey_sufficientlyVisible()])
        EarlGrey.selectElement(with: tabButtonMatcher).perform(grey_tap()).assert(grey_sufficientlyVisible())

导航栏按钮也类似

    let navMatch: GREYMatcher = grey_allOf([grey_accessibilityID("Something"), grey_accessibilityTrait(UIAccessibilityTraitButton), grey_sufficientlyVisible()])
    EarlGrey.selectElement(with: navMatch).perform(grey_tap())
4

1 回答 1

4

您必须grey_sufficientlyVisible从匹配器中删除，因为它没有意义。该匹配器保证在assert语句中运行良好，但作为匹配器参数传递似乎效率低下。

EarlGrey 与运行循环上的触摸事件交互，通常，它与应用程序以及真实用户交互。在这种情况下，它不太可能的测试会很快，尤其是与在 UI 元素上调用选择器而不是传递触摸事件的 KIF 相比。这还不错，这是功能测试的预期行为。顺便说一句，您可以通过禁用动画来加速测试：

GREYTestHelper.enableFastAnimation()

关于您与匹配器相关的问题，我建议您尝试几种方法并找到一种适合您情况的方法。

乍一看，找到一个UITabBarItemusing应该是值得的grey_kindOfClass。

匹配器示例（不工作）

grey_allOf([grey_kindOfClass(UITabBarItem.self), grey_text(title)])

但这不是有效的解决方案。让我们看看视图层次结构：

在此处输入图像描述

所以如果你依赖UITabBarItem它是行不通的，因为没有这样的元素。你可以看到，有一个私有的 UIKit 类被调用UITabBarButton，它不应该与之交互。而且，它不是 的子类UIButton，而是 的子类UIControl

相反，我建议在UITabBar使用inRoot函数时选择元素。

匹配器示例（工作）

EarlGrey.selectElement(with: grey_text(tabbarTitle))
        .inRoot(grey_kindOfClass(UITabBar.self))
        .perform(grey_tap())

在这种情况下，您会找到一个元素，该元素具有预期的文本并且位于UITabBar.

对于导航栏上的选择元素，可以使用此匹配器的变体：

在导航栏上查找元素的匹配器示例

EarlGrey.selectElement(with: grey_kindOfClass(UIButton.self))
        .inRoot(grey_kindOfClass(UINavigationBar.self))
于 2018-11-18T08:19:51.017 回答