这是个非常务实的问题——很多人在重构引入设计模式后，都会纠结测试的边界该怎么划定。先给你个核心结论：不是强制要求，但绝大多数情况下，补充针对单个策略的白盒测试会让你的测试套件更健壮，长期维护成本更低。

先聊聊黑盒测试的局限性 #

你现有的黑盒测试能覆盖最终输出，这已经是很扎实的基础了，但它有个明显的短板：只能验证“结果对不对”，没法帮你快速定位问题。举个例子：如果某个策略的逻辑出了bug，黑盒测试会失败，但你得花时间排查——是策略选择逻辑错了？还是某个策略的实现有问题？如果有单独的策略测试，你直接跑对应策略的用例就能锁定问题，不用在整个业务流程里瞎找。

策略模式的本质是拆分，测试也该对应拆分 #

策略模式的核心就是把复杂的分支逻辑拆成一个个独立、内聚的职责单元。既然代码结构做了拆分，测试逻辑也应该跟上：

• 你可以更全面地测试单个策略的边界场景：比如某个策略处理极端输入、异常情况的表现，这些场景在黑盒集成测试里可能很难覆盖到——毕竟集成测试通常聚焦主流业务流程。
• 后续修改某个策略时，只需要跑这个策略的测试用例就行，不用跑完整的黑盒测试套件，能节省不少时间。
• 如果以后要把某个策略复用在其他业务场景里，现成的单元测试已经能证明它的可靠性，不用再重新写一遍集成测试。

什么时候可以考虑不补充？ #

如果你的策略逻辑特别简单（比如只是返回固定值、做个加减运算），而且黑盒测试已经完全覆盖了所有可能的策略分支，那确实可能有点冗余。但说实话，这种情况很少见——毕竟如果逻辑这么简单，你大概率也不会用策略模式来重构对吧？

建议的平衡方式：分层测试 #

不用二选一，把黑盒和白盒测试结合起来效果最好：

1. 保留原有的黑盒测试，用来验证整体业务流程的正确性（比如不同输入对应不同策略的最终输出是否符合预期）。
2. 补充针对每个策略的单元测试，验证单个策略内部逻辑的正确性（比如边界值、异常处理、特殊场景）。
3. 策略的“选择逻辑”（比如哪个输入触发哪个策略）不用单独测试，这部分已经被黑盒测试覆盖了。

总的来说，补充策略的白盒测试绝对不是冗余操作，而是让你的测试体系更有针对性、更易维护的优化。毕竟测试的核心目标不只是“验证结果正确”，更是“快速定位问题、降低长期维护成本”。

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