Kola Tool Chain

Understand how SDK, IntelliJ, Gradle, and Kola DSL files work together in the ApiHug testing flow.

What This Page Covers

This page explains the operational toolchain behind Kola, not just the DSL syntax.

Use it when you need to understand which moving parts must stay aligned before Kola scenarios can run reliably.

Core Components

Kola depends on four cooperating layers:

Proto contracts define the API surface and generated metadata.
ApiHug SDK provides the runtime and testing support used by generated projects.
IntelliJ plugin helps create and edit Kola files and related proto structures.
Gradle tasks compile, generate, and execute contract-aware tests.

If one of these layers is outdated, the testing flow usually degrades quickly.

Recommended Setup

Keep the following versions aligned:

the project SDK version from your ApiHug BOM or platform dependencies
the IntelliJ plugin version used by the team
the Kola-related Gradle setup in the proto-driven module

For current artifacts:

JetBrains Marketplace

How the Flow Works

1. Contract design starts in proto

Service, request, response, entity, and supporting metadata are defined in the proto-driven module.

2. Kola scenarios live beside the contract

Kola works best when the scenario DSL files evolve together with the same module that owns the API contract.

3. Gradle executes the contract-aware test task

The typical entry command is:

Terminal

./gradlew.bat {proto_module}:kolaTest --stacktrace

This is why Kola is best treated as a toolchain concern, not just a standalone DSL feature.

IntelliJ Responsibilities

The IntelliJ plugin helps with:

creating proto and Kola-related files faster
reducing boilerplate when editing contract structures
keeping common editing tasks inside the IDE

The plugin is not the execution engine. It improves authoring speed, while Gradle and the SDK still own generation and runtime execution.

Gradle Responsibilities

Gradle is responsible for:

wiring generation and test execution into the module lifecycle
resolving the SDK/runtime dependencies needed by Kola
exposing a reproducible team entrypoint for contract-aware tests

If your build does not expose the Kola task correctly, the DSL files alone are not enough.

Result

When the SDK, plugin, proto module, and Gradle task stay aligned, Kola becomes a repeatable team workflow for contract-aware testing instead of a one-off local experiment.