React Testing Library 中关于只读属性的测试要点解析

在 React 组件测试中，处理 HTML 元素的布尔属性时需要注意一些特殊行为。本文将通过一个实际案例，讲解如何正确测试 React 组件中的只读(readonly)属性。

问题背景

在 React 组件开发中，我们经常需要根据业务逻辑控制表单元素的可编辑状态。一个常见的做法是通过 readOnly 属性来控制输入框是否为只读状态。然而，在测试这类组件时，开发者可能会遇到一些预期之外的行为。

案例重现

假设我们有一个 DataField 组件，它接收一个 isEditable 的布尔属性。当 isEditable 为 false 时，我们希望将内部的 input 元素设置为只读状态。

组件代码可能如下所示：

<input
  readOnly={!isEditable}
  className="..."
  {...props}
/>

在测试中，我们可能会这样编写断言：

expect(inputField).toHaveAttribute('readonly', 'true');

问题分析

上述测试可能会失败，并显示如下错误信息：

Expected the element to have attribute:
    readonly="true"
Received:
    readonly=""

这是因为 HTML 布尔属性的处理方式与常规属性不同。在 HTML 中，布尔属性的存在本身就表示 true，而它的值并不重要。这就是为什么我们看到的 readonly 属性值为空字符串。

解决方案

在测试布尔属性时，我们有以下几种更合适的断言方式：

1. 检查属性是否存在：

expect(inputField).toHaveAttribute('readonly');

2. 使用专门的布尔属性匹配器（如果测试库支持）：

expect(inputField).toBeReadOnly();

3. 检查 DOM 属性而非 HTML 属性：

expect(inputField.readOnly).toBe(true);

深入理解

这种行为的根源在于 HTML 规范对布尔属性的定义。在 HTML 中，像 readonly、disabled、checked 这样的属性，只要出现在元素上就会被浏览器视为 true，无论它们的值是什么。React 和 JSDOM 都遵循了这一规范。

因此，在编写测试时，我们不应该过于关注这些属性的具体值，而应该关注它们是否存在或对应的 DOM 属性值是否正确。

最佳实践

1. 对于布尔属性，优先检查 DOM 属性而非 HTML 属性
2. 考虑使用测试库提供的专门匹配器（如 toBeDisabled()、toBeChecked() 等）
3. 在组件中明确布尔属性的处理逻辑，保持一致性
4. 在团队中建立统一的测试规范，避免混淆

通过理解这些底层原理，我们可以编写出更健壮、更准确的组件测试，确保 UI 行为符合预期。