我正在试验 (Xcode 7) UI XCTestCase 测试用例，我偶然发现了一个 UIView 的问题，其中我有一个包含许多单元格(4000+)的 UITableView。

当应用程序正常运行时，仅渲染可见单元格，完全没有性能问题。 但是，如果我在记录 XCTestCase 的上下文中运行该应用程序并导航到此屏幕，模拟器会卡住，这显然是因为每个单元格都呈现为好像它是可见的。 如果我尝试手动编写导航脚本并运行 XCTestCase，则测试用例会在导航到此屏幕后立即失败，并退出并显示“UI 测试失败 - 无法获取刷新的快照”，这显然又是因为所有单元格都被渲染了，这没有及时完成。

我认为这与以下事实有关:测试框架构建了所显示屏幕的完整元模型，将 4000 多个单元格中的每一个单元格添加到 View 树层次结构中。

我尝试添加一个期望值，希望这会给测试容器足够的时间来完成所有单元格的渲染，但这不起作用。

有解决办法吗？是否可以以某种方式跳过构建 UI 树层次结构的一部分或其他内容？ 我的目标是能够为此屏幕编写 UI 测试。

最佳答案

如果您可以使用 firstMatch 而不是 element，并且还可以避免 count，您也许可以避免呈现整个表格。

我进行了一项测试，检查表格前两个单元格中的预期标签。起初，我使用 app.table.cells.element(boundBy: 0) 和 app.table.cells.element(boundBy: 1) 找到第一个和第二细胞。这导致在我可以访问单元格之前呈现整个表格。

我调整了我的测试，使其不太精确，但对我来说仍然足够好(考虑到否则会花费大量时间)。相反，我将 matching 与预期标签值上的谓词一起使用，使用 firstMatch 来查找与我想要的条件匹配的第一个单元格。这样一来遍历就停止了(因为它们在表的顶部，所以很快)。

这是前后的代码。

之前(慢，但更精确):

private func checkRhymes(query: String, expectedFirstRhyme: String, expectedSecondRhyme: String) {
    let table = app.tables.element
    let cell0 = table.cells.element(boundBy: 0)
    let cell1 = table.cells.element(boundBy: 1)
    let actualRhyme0 = cell0.staticTexts.matching(identifier: "RhymerCellWordLabel").firstMatch.label
    let actualRhyme1 = cell1.staticTexts.matching(identifier: "RhymerCellWordLabel").firstMatch.label

    XCTAssertEqual(expectedFirstRhyme, actualRhyme0, "Expected first rhyme for \(query) to be \(expectedFirstRhyme) but found \(actualRhyme0)")
    XCTAssertEqual(expectedSecondRhyme, actualRhyme1, "Expected first rhyme for \(query) to be \(expectedSecondRhyme) but found \(actualRhyme1)")
}

更快，但不够精确(但足够好):

private func checkRhymes(query: String, expectedFirstRhyme: String, expectedSecondRhyme: String) {
    let table = app.tables.firstMatch
    let label0 = table.cells.staticTexts.matching(NSPredicate(format: "label = %@", expectedFirstRhyme)).firstMatch
    let label1 = table.cells.staticTexts.matching(NSPredicate(format: "label = %@", expectedSecondRhyme)).firstMatch

    // We query for the first cells that we find with the expected rhymes,
    // instead of directly accessing the 1st and 2nd cells in the table,
    // for performance issues.
    // So we can't add assertions for the "first" and "second" rhymes.
    // But we can at least add assertions that both rhymes are visible,
    // and the first one is above the second one.
    XCTAssertTrue(label0.frame.minY < label1.frame.minY)
    XCTAssertTrue(label0.isHittable)
    XCTAssertTrue(label1.isHittable)
}

引用: https://developer.apple.com/documentation/xctest/xcuielementquery/1500515-element

Use the element property to access a query’s result when you expect a single matching element for the query, but want to check for multiple ambiguous matches before accessing the result. The element property traverses your app’s accessibility tree to check for multiple matching elements before returning, and fails the current test if there is not a single matching element.

In cases where you know categorically that there will be a single matching element, use the XCUIElementTypeQueryProvider firstMatch property instead. firstMatch stops traversing your app’s accessibility hierarchy as soon as it finds a matching element, speeding up element query resolution.

关于ios - XCTestCase - iOS UI 测试 - 处理具有多个单元格的 UITableViews，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/33529380/