测试时应复用应用内功能还是手动显式完成测试准备？

先给核心结论：没有绝对的“应该/不应该”，完全取决于你写的测试类型，以及测试要达成的目标。

1. 单元测试：必须隔离，别碰其他真实模块 #

单元测试的本质是验证单个模块（比如某个命令处理器、查询逻辑）的独立正确性，所以arrange阶段绝对不能依赖其他真实的应用模块。举个实际例子：

• 如果你测的是CreateOrderCommandHandler，别用GetUserQuery去真实查询用户数据，而是手动构造一个User对象，或者用mock工具模拟查询结果。
• 要是你依赖了其他模块，一旦那个模块出bug，你的单元测试就会失败——这完全偏离了单元测试的初衷，你本来是要测当前模块，结果却被其他模块的问题干扰，排查起来也会混乱。

2. 集成/系统测试：放心用，这本来就是测试目标 #

集成测试（验证模块间协作）、系统测试（验证整个系统流程）的核心就是看各个模块一起工作时的表现，所以用其他模块的功能做准备是完全合理的，甚至是必要的。比如：

• 测试GetOrderQuery的正确性时，你可以先用真实的CreateOrderCommandHandler插入测试订单，再执行查询验证结果。
• 这种情况下，某个模块故障导致“无关”测试失败是好事：它直接反映了真实系统中模块故障的传导路径，能帮你提前发现集成漏洞，而不是等到上线才暴露问题。

3. 中间场景：组件测试，按需选择 #

如果是测试一组相关模块（比如CQRS同一业务上下文下的命令和查询），可以根据情况灵活选择：

• 若你想验证这组模块的协作逻辑，用真实依赖没问题，但要做好测试隔离（比如用独立的测试数据库，每个测试后清空数据）；
• 若你还是想聚焦单个模块的逻辑，那依然要保持隔离。

关于“无关测试失败”的对错判断 #

• 单元测试中出现这种情况：坏，说明测试边界没做好，单元测试应该只对当前模块的代码变化敏感。
• 集成/系统测试中出现这种情况：好，这是测试的价值所在——它能帮你快速定位系统中某个模块故障影响的范围，提前修复链路问题。但要注意给测试加清晰的日志，比如标注哪个模块抛出了异常，这样排查起来才高效。

实用实践建议 #

• 分层测试：单元测试做隔离验证，集成测试做协作验证，两者搭配，既保证单个模块的正确性，又能覆盖系统链路。
• 依赖前置验证：如果在集成测试中依赖其他模块，确保那些模块的单元测试已经覆盖核心逻辑，减少因依赖模块的低级bug导致的测试误报。
• 测试数据隔离：不管用不用其他模块，每个测试用例的测试数据都要独立，避免测试之间互相污染（比如用事务回滚、测试后清理数据等方式）。

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