Skip to content

JVM Frameworks

The Stove lifecycle is the same across JVM frameworks: register systems, expose their configuration, start the application under test, then run assertions through stove { }. The framework starter only changes how the app is booted.

What changes between starters Runner startup, readiness behavior, DI/test-dependency hooks, and bridge support differ by framework. System modules, the assertion DSL, reporting, tracing, dashboard, and MCP keep the same shape across Spring · Ktor · Micronaut · Quarkus.

The four starters

Spring BootBridge ✓

runApplication(...) wrapped in run(args); optional bridge access to the Spring context.

Guide Example → wizard
KtorBridge ✓

embeddedServer(...) wrapped in run(args); bridge support for Koin or Ktor-DI.

Guide Example → wizard
MicronautBridge ✓

ApplicationContext startup wrapped in run(args); bridge access to Micronaut beans.

Guide Example → wizard
QuarkusBridge ✗

@QuarkusMain plus Quarkus.run(*args); use readiness because bridge is not available.

Guide Example → wizard

How the runner block differs

Spring Boot

springBoot(
  runner = { params -> com.app.run(params) },
  withParameters = listOf("server.port=8080")
)

Ktor

ktor(
  runner = { params -> com.app.run(params, wait = false) },
  withParameters = listOf("server.port=8080")
)

Micronaut

micronaut(
  runner = { params -> com.app.run(params) },
  withParameters = listOf("micronaut.server.port=8080")
)

Quarkus

quarkus(
  runner = { params -> com.app.main(params) },
  withParameters = listOf("quarkus.http.port=8080")
)

Everything around the runner stays the same: httpClient, postgresql, kafka, wiremock, tracing, reporting, and test assertions.

Bridge availability

Framework Bridge Why
Spring Boot ✓ exposes the running ApplicationContext
Ktor ✓ exposes the selected Koin or Ktor-DI container
Micronaut ✓ exposes the running ApplicationContext
Quarkus ✗ CDI lifecycle integration not yet shipped

For Quarkus, drive verification through HTTP, DB queries, and Kafka assertions instead of using<T> { ... }.

What stays identical

  • Stove() lifecycle and with { } registration order
  • every system module (stove-postgres, stove-kafka, stove-wiremock, ...)
  • the test DSL: stove { http { } postgresql { } kafka { } }
  • reporting, tracing, dashboard, MCP
  • recipes. The same flow swaps starter freely

Where to next