Selenium PageObject开发：是否应该使用PageFactory？

在使用Selenium的PageObject模式时，纠结要不要用PageFactory。已知它的核心优势是空安全和WebElement延迟初始化（仅在使用时才初始化），但在Kotlin里，初始化后的WebElement得频繁做空检查，示例代码如下：

PageObject类代码 #

@FindBy(id = "boligLink")
val boliglink: WebElement? = null

调用代码（通常在Step Definition类中） #

boliglink?.click()

// 或者
return boliglink?.isDisplayed()

我的疑问：

• 除了缓存（仅多次访问同一元素时有用），PageFactory相比每次访问元素用try/catch（可抽象封装）的方式，还有其他优势吗？
• 下面这种try/catch的写法，能不能达到和PageFactory基本相同的效果？

try/catch实现示例 #

return try { 
    getElementInElement(element, By.cssSelector("[data-e2e-selector=boliginLink]")) 
} catch (e: NoSuchElementException) { 
    throw NoSuchElementException("Couldn't find link to boliginformasjon") 
}

PageFactory的额外优势 #

• 代码简洁易读：通过@FindBy注解声明元素，把定位器与业务操作分离，PageObject类结构更清晰，不用在业务方法里重复写findElement或自定义查找逻辑。
• 统一维护定位器：所有元素定位规则集中在类的字段注解上，后续修改定位方式（比如从id切换到css选择器），只需要修改注解参数，不用在多个业务方法中逐一修改查找代码。
• 内置异常处理封装：PageFactory已经封装了元素查找的基础异常逻辑，不用为每个元素手动编写try/catch，虽然Kotlin需要做空安全处理，但相比重复编写异常捕获逻辑，还是更省心。
• 支持扩展定制：可以自定义PageFactory的元素处理器，比如添加全局的元素等待、高亮逻辑等，不用从零开始封装，直接复用Selenium的扩展能力。

try/catch方式的效果对比 #

你写的try/catch方式确实能实现元素查找失败时抛出自定义异常的效果，和PageFactory在"元素不存在时触发异常"这一点上逻辑一致，但两者存在以下差异：

• 初始化时机不同：PageFactory的WebElement是真正的懒加载——只有调用元素方法（如click()、isDisplayed()）时才会执行查找；而你的try/catch写法在调用getElementInElement()时就会立即查找元素，属于即时初始化，不是懒加载。
• 代码冗余度不同：即使把try/catch抽象成工具方法，每个业务方法里还是要显式调用；而PageFactory只需要在类初始化时调用一次PageFactory.initElements()，后续直接使用注解声明的元素即可，代码更简洁。
• 缓存机制缺失：PageFactory默认开启元素缓存，频繁操作同一元素时能减少重复查找的开销；而你的try/catch写法每次调用都会重新查找元素，没有缓存能力。

取舍建议 #

如果你的测试用例元素访问频率低，或者更倾向于手动控制元素查找逻辑，那try/catch+自定义工具方法的方式完全可行；但如果项目规模大、元素数量多，或者需要统一管理定位器、复用扩展能力，PageFactory的优势会更明显。另外，在Kotlin里可以通过封装扩展函数减少空检查的繁琐：

fun WebElement?.safeClick() {
    this?.click() ?: throw NoSuchElementException("元素未找到，无法执行点击操作")
}

调用时只需写boliglink.safeClick()，不用每次重复写?.click()。

内容的提问来源于stack exchange，提问作者kakemonsteret