当前位置：首页 > news >正文

功能上下文划分与测试替身选择策略

news 2026/5/13 2:09:56

功能上下文划分与测试替身选择策略

一、用软件架构划分功能上下文

划分功能上下文最直接的方法是软件架构。架构定义了系统由哪些组件构成以及各组件之间的关系，每个组件负责明确的功能单元，天然对应一个功能上下文。

以一个典型的后端三层架构为例，业务场景是"用户获取所有在售商品"。按照架构模式引入对应组件：

ProductsAPI：通过 HTTP 协议将 ProductService 暴露为 RESTful API；
ProductService：封装产品目录相关的业务逻辑，通过 ProductDAO 访问持久化数据；
ProductDAO：封装对持久化数据访问的相关逻辑。

按照这三个功能上下文，可以构造相互关联的 Q1 与 Q2 测试：Q2 的功能测试覆盖整个调用链（HTTP interface → Application Logic → Persistent），而三个 Q1 测试分别只覆盖对应的单个组件。当 Q2 测试失败时，至少有一个 Q1 测试也会失败，失败的 Q1 测试直接指明了问题所在的组件。

值得注意的是，Q1 还是 Q2 的判断标准是测试的受众与目的，而不是测试技术本身。ProductDAO 的测试通常需要使用内存数据库（如 H2），从测试技术角度看属于集成测试，但其受众仍然是技术导向，因此仍属于 Q1 象限，而不是 Q2。

二、五种测试替身及其适用场景

如果没有测试替身（Test Double），就无法独立测试架构中的单个组件。以 ProductsAPI 为例，如果直接使用new ProductServiceImpl()，测试就会穿透所有层，变成一个功能测试，而不是针对 HTTP interface 层的组件测试。

解决方案是引入依赖注入（Dependency Injection），在测试中注入替身而非真实实现。目前广泛使用的测试替身有五种：

哑对象（Dummy Object）：不会被实际使用，只是用来填充参数列表，满足方法签名的需求。

假实现（Fake Object）：一种实际可用的简化实现，但不会用于生产环境。内存数据库（如 H2）是典型例子——对绝大多数测试场景功能已足够，但不适合生产。

存根对象（Stub）：为测试中调用的方法提供预先准备好的答案，只响应特定场景，无法看作可用的完整实现。与 Fake 的区别在于，Stub 只满足特定测试场景，而 Fake 是一个可以工作的简化版本。

间谍对象（Spy）：特殊的 Stub，除了响应方法调用外，还会记录调用信息（如某方法被调用了多少次），用于事后验证。

模拟对象（Mock）：对将要进行的调用存在明确预期，按预先编排的答案响应所有调用，若收到不符合预期的调用则抛出异常，最终验证时检查是否收到了所有预期调用。

在前面的三层架构例子中，ProductDAO 的测试使用 Fake（内存数据库），ProductService 和 ProductsAPI 的测试使用 Stub。

三、合并功能上下文的策略选择

除了五种测试替身，还有一个选择：使用真实对象。使用真实对象意味着合并不同的功能上下文。

例如，让 ProductsAPI 直接使用真实的ProductServiceImpl，但给ProductServiceImpl注入一个ProductDAOStub。这样，HTTP interface 层和 Application Logic 层就被合并为一个测试上下文，只有 Persistent 层保持独立。

这种合并在某些场景下非常合理。如果 HTTP interface 层只有极少的逻辑（主要是将 Application Logic 层的返回值做格式转换），那么为它单独写一套 Q1 测试的价值很低，合并两个上下文可以减少低价值测试，降低维护成本。

测试策略的本质是权衡：架构上存在多个功能上下文，但测试策略可以选择将某些上下文合并，以控制测试成本。关键是这个决策要有意识地做出，而不是因为"不知道怎么写测试替身"而被迫合并。