Kola 的设计思路

理解 Kola 为什么采用 DSL、为什么依赖这套工具链，以及它如何服务契约优先测试。

本页说明

这一页解释的是 Kola 为什么这样设计，而不仅仅是怎么执行。

如果你想理解 Kola 在 DSL、运行时依赖和契约优先测试流程上的取舍，请先看这一页。

传统 API 测试很容易滑向两个方向：

Kola 的设计目标，就是把场景意图、契约结构和团队协作流程重新拉近。

Kola 采用 BDD 风格，不是为了追随某个特定框架，而是因为 API 场景用下面这种结构更容易沟通：

这种表达方式更适合产品、前端、后端和测试一起讨论。

Kola 使用 Groovy 风格 DSL，是因为它在三个方面比较平衡：

目标不是发明一门新的语言，而是让测试场景既轻量、又能很好地融入现有工程。

Kola 不打算重造整套测试运行栈，而是建立在熟悉的 JVM 测试基础设施之上。

常见依赖包括：

这样做的好处是：团队不需要为了引入 Kola，再额外学习一整套完全陌生的底层工具链。

Kola 首先是为 proto 驱动的 ApiHug 项目设计的。

这种前提带来三点优势：

Kola 也能覆盖非 ApiHug 的 API，但项目越接近 ApiHug 的契约模型，收益通常越大。

Kola 的设计目标非常务实：让场景更易读、执行更贴近契约、工具链又足够熟悉，团队可以在不重建整套测试体系的前提下采用它。