NgRx Signals 测试辅助工具：`unprotected` 函数的设计思考

在 NgRx Signals 的状态管理方案中，SignalStore 提供了一种响应式的状态管理方式。然而在测试场景下，开发者经常需要直接修改受保护的状态来进行测试准备。本文将深入探讨 NgRx 社区关于测试辅助工具的设计讨论和技术决策。

背景与需求

SignalStore 默认情况下会保护内部状态，防止外部直接修改，这是良好的封装性原则。但在单元测试中，我们经常需要：

1. 快速设置初始测试状态
2. 模拟特定状态场景
3. 验证状态变更逻辑

目前缺乏官方推荐的测试工具方法，导致开发者需要寻找各种变通方案。

解决方案讨论

社区提出了几种设计方案：

1. unprotected 函数方案

import { unprotected } from '@ngrx/signals/testing';

const store = TestBed.inject(UsersStore);
patchState(unprotected(store), setAllEntities(usersMock));

这种方案通过一个简单的包装函数，临时解除状态保护，允许直接修改。

2. overrideState 方案

借鉴 Angular TestBed 的 override 系列方法：

overrideState(store, newState);

优势是符合 Angular 开发者已有的心智模型，同时隐含"这是测试专用方法"的语义。

3. injectUnprotectedStore 方案

const store = injectUnprotectedStore(UsersStore);
patchState(store, setAllEntities(usersMock));

这种方法通过专门的注入函数，明确区分了测试环境和生产环境。

技术考量

1. 类型安全：所有方案都需要确保类型系统能够正确识别修改后的状态类型
2. 测试意图表达：API 设计应该清晰表达这是测试专用工具
3. 误用防范：尽量减少在生产代码中误用的可能性
4. 开发者体验：符合 Angular/NgRx 开发者已有的使用习惯

最佳实践建议

基于讨论，推荐以下测试模式：

// 推荐方式：明确测试初始化
const store = injectStore(UsersStore, {
  initialState: setAllEntities(usersMock)
});

// 或者在已有实例上修改
const store = TestBed.inject(UsersStore);
patchState(unprotected(store), setAllEntities(usersMock));

对于复杂测试场景，可以考虑分层策略：

1. 使用 injectStore 进行基础状态设置
2. 通过业务方法测试正常流程
3. 仅在必要时使用 unprotected 模拟异常状态

实现原理

这类测试工具的核心实现通常会涉及：

1. 类型转换：将受保护类型转换为可写类型
2. 状态访问：提供对底层 Signal 的直接访问
3. 作用域限制：确保仅在测试环境下可用

总结

NgRx Signals 的测试工具设计体现了在开发者体验和软件工程原则间的平衡。最终方案将提供灵活而安全的测试能力，同时保持生产代码的封装性。开发者可以根据具体测试需求选择合适的工具方法，但应始终注意测试的真实性和可维护性。