
194
|
第
13
章
数据库或网络服务等。因此,集成测试能覆盖更完整的代码路径。由于必须初始化和配置
这些其他依赖项,集成测试可能会比单元测试更慢、更脆弱。要执行测试,此方法将真实
的变量(如网络延迟)与服务间端到端通信相结合。当测试对象从独立底层代码单元切换
到各单元组合后的交互方式时,最终结果更能使我们确信系统运行符合预期。
由于要处理的依赖项复杂性不同,集成测试的形式也不同。当所需的依赖关系相对简单
时,集成测试可能看起来像基类,并建立了一些共享的依赖关系(如处于预配置状态的数
据库),其他测试也可基于此扩展。集成测试的复杂度可能会随服务复杂性增强,需要监
督系统来协调支持测试依赖项的初始化或配置。
Google
内部有团队专门负责基础架构建
设,为常见的基础架构服务启用标准化的集成测试设置。对于使用持续构建和交付系统
(如
Jenkins
)的组织来说
,集成测试可以与单元测试一起或分开单独运行,具体情况视代
码库规模和项目中可用测试用例数而定。
在构建集成测试时,请牢记第
5
章中讨论的原则:确保测试需要的数据和系
统不会带来安全风险。数据库提供了一系列丰富的真实业务数据,因此很可
能将实际的数据库镜像复制到测试环境中。但应避免使用这种不当的模式,
任何人执行使用这些数据库的测试用例时,都可接触其中可能包含的敏感数
据。这样的实现方式违背了最小特权原则,并可能带来安全风险。相反,可
使用不敏感的测试数据作为系统的种子(
seed
)。使用这种方法后,还能轻松
地将测试环境清空至已知的干净状态,进而降低集成测试的脆弱性。 ...