广泛集成测试

当我们对自动化测试表示赞扬时，也持续看到许多组织在我们认为无效的 广泛集成测试 上投入过多。“集成测试”这个术语在表述上有些模糊不清，我们尝试引用 Martin Fowler 在该主题上的bliki 条目描述——该分类指的是需要所有运行时依赖项的实时版本的测试。这样的测试显然是昂贵的，因为它需要具备所有必要基础设施、数据和服务的全功能测试环境。管理所有这些依赖项的正确版本需要大量的协调工作，这往往会拖慢发布周期。最后，测试本身通常是脆弱且无用的。例如，要确定测试失败是由于新代码、版本依赖性不匹配还是环境不足，而错误信息很少有助于挖掘问题源头。当然，这些批评并不意味着我们认为自动化的“黑盒”集成测试普遍存在问题，但我们的确发现了一种更有帮助的方法——就是平衡对信心的需求与发布频率。可以先假设对运行时依赖项的一组响应来验证被测试系统的行为，然后验证这些假设的两个阶段来完成。第一阶段使用服务虚拟化来创建运行时依赖项的测试替身，并验证被测试系统的行为。这简化了测试数据管理问题，并允许进行确定性测试。第二阶段可以使用契约测试来验证这些环境假设与真实依赖项。