4、查找元素：onNodeWithText、onNodeWithTag、onNodeWithContentDescription
UI测试说白了就是让机器代替你的眼睛，去检查屏幕上有没有你要的东西。但机器怎么知道「这个按钮」就是「那个按钮」呢？这就需要我们告诉它：嘿，去找那个写着「登录」的文本，或者去找那个tag是submit_button的组件。
Compose测试框架提供了三种最常用的查找方式。我刚开始写测试时，经常搞混它们各自的适用场景。后来踩了几个坑，才真正摸清楚它们的脾气。
4.1 onNodeWithText：按文本内容查找
这是最直观的一种方式。你的界面上显示什么文字，你就用什么文字去找。
// 查找显示"登录"的文本节点
composeTestRule.onNodeWithText("登录")
// 查找包含"欢迎"的文本（支持子串匹配）
composeTestRule.onNodeWithText("欢迎", substring = true)
// 配合正则表达式
composeTestRule.onNodeWithText(Regex("\\d+元"))适用场景：按钮文字、标题、标签、列表项内容。
核心要点：默认是精确匹配，区分大小写。如果你只想匹配一部分内容，记得设置substring = true。
我的经验：我在项目中遇到过一个问题——同一个界面上有两个「确认」按钮，一个在弹窗里，一个在页面底部。直接用onNodeWithText("确认")会报错，说找到多个节点。这时候就需要结合父容器或者使用索引来定位。
4.2 onNodeWithTag：按语义标签查找
这个方式更「程序员思维」。你给组件贴个标签，测试时直接按标签找。就像给你的代码加注释一样，清晰明了。
// 在Compose代码中设置标签
Text(
text = "用户名",
modifier = Modifier.testTag("username_label")
)
// 在测试中查找
composeTestRule.onNodeWithTag("username_label")适用场景：图标按钮、无文字组件、需要唯一标识的复杂布局。
注意：testTag是Modifier的扩展函数，不是所有组件默认都有。你必须在代码里显式加上。我曾经接手过一个项目，整个代码库没有一个testTag，写测试时简直想哭。
为什么推荐用testTag？因为文本可能会变。产品经理今天说「登录」，明天改成「立即登录」，你的测试就挂了。但testTag是开发定义的，一般不会轻易改。
4.3 onNodeWithContentDescription：按无障碍描述查找
这个方式原本是为无障碍功能设计的。屏幕阅读器会朗读这个描述，帮助视障用户理解界面。但在测试中，它也能派上用场。
// 在Compose代码中设置
Icon(
imageVector = Icons.Default.Search,
contentDescription = "搜索图标"
)
// 在测试中查找
composeTestRule.onNodeWithContentDescription("搜索图标")适用场景：图标、图片、纯图形按钮。
最佳实践：我建议所有图标按钮都加上contentDescription。一方面方便测试，另一方面也是无障碍开发的基本要求。一举两得，何乐而不为？
4.4 三种方式的对比
| 查找方式 | 匹配依据 | 优点 | 缺点 |
|---|---|---|---|
| onNodeWithText | 文本内容 | 直观，不需要额外代码 | 文本易变，可能重复 |
| onNodeWithTag | testTag | 稳定，不受UI文案影响 | 需要手动添加tag |
| onNodeWithContentDescription | 无障碍描述 | 兼顾无障碍，适合图标 | 不是所有组件都有 |
4.5 组合使用与链式调用
实际项目中，很少只用一种方式。你想想看，一个复杂的界面可能有几十个节点。怎么精确找到目标？
// 先按文本找到父容器，再在里面按tag找子节点
composeTestRule
.onNodeWithText("用户信息")
.onChildren()
.onNodeWithTag("edit_button")
// 或者使用Matcher组合
composeTestRule.onNode(
hasText("确认") and hasTestTag("submit_btn")
)避坑指南：我曾经在测试一个列表时，用onNodeWithText("删除")去找每一行的删除按钮。结果因为列表有10行，找到了10个匹配项，测试直接报错。后来改用onNodeWithTag("delete_btn_3")配合索引，才解决问题。
4.6 知识体系一览
下面这张图帮你理清这三种查找方式的关系和选择逻辑：
4.7 实际项目中的选择策略
说了这么多，到底该用哪个？我个人的习惯是这样的：
- 优先用testTag——稳定、可控、不受UI变更影响。写代码时多花30秒加个tag，测试时能省半小时。
- 文本内容作为备选——适合快速验证原型，或者测试文案本身是否正确。
- contentDescription作为补充——专门对付图标和图片，顺便把无障碍测试也做了。
重要提醒：不管用哪种方式，都要确保查找结果是唯一的。如果找到多个节点，测试框架会直接抛异常。你可以用onFirst()取第一个，或者用filterToOne()精确过滤。
嗯，这三种查找方式其实没有绝对的优劣。关键是根据你的场景选对工具。就像修车一样，扳手和螺丝刀各有各的用处，你不能说哪个更好。
记住一点：测试代码也是代码，它需要维护。选择一种让未来同事（包括三个月后的你自己）能一眼看懂的方式，比追求「炫技」重要得多。