Allure reporting for the TestBalloon test framework — DSL-only, with capability parity to allure-junit4.

// build.gradle.kts
plugins {
    id("de.infix.testBalloon") version "<testballoon-version>"
}

dependencies {
    testImplementation("io.github.uoooo:testballoon-allure:<version>")
}

// Activate reporting for the whole test module:
class MyTestSession : AllureTestSession()

// Annotate tests with Allure metadata and runtime steps:
val mySuite by testSuite(
    "checkout",
    testConfig = TestConfig.allure {
        epic("Shop")
        feature("Checkout")
        severity(AllureSeverity.CRITICAL)
    }
) {
    test("pays with a saved card") {
        allureStep("prepare cart") { /* ... */ }
        allureAttachment("receipt", receiptJson, "application/json", fileExtension = "json")
    }
}

Use the testballoon-allure version whose -K suffix matches your TestBalloon variant: for TestBalloon 1.0.1-K<kotlin>, use testballoon-allure 0.1.0-K<kotlin>.

Supported Kotlin versions: 2.2.0, 2.2.21, 2.3.0, 2.3.20, 2.4.0 (Kotlin 2.2.0 is the support floor) — see RELEASING.md for how the list evolves.

Results are written to allure.results.directory (default allure-results); generate a report with the Allure CLI: allure serve <results-directory>.

By default the Suites view carries a single suite label naming the top-level suite — what allure-junit4 emits for the test class; nested structure stays in fullName and the step chain. Declaring suite/parentSuite/subSuite explicitly replaces the derived label — like allure-pytest's suite decorators:

testConfig = TestConfig.allure {
    suite("Shop")
    subSuite("Checkout")
}

displayName("…") overrides a test's list entry the same way (the @DisplayName equivalent of allure-junit4), leaving fullName, the step chain and history tracking untouched.

hideInReportPath() on a nested suite removes that structural level from fullName, the step chain and history tracking — for wrapper suites that are implementation detail, e.g. a robolectricTestSuite hosting externally defined content. allure-junit4 equally keeps wrapper suites (@RunWith(Suite.class)) out of its reports.

Use the plain testballoon-allure module together with TestBalloon's Robolectric integration — with an AllureTestSession subclass in place (see above), no extra setup is needed:

val mySuite by testSuite(
    testConfig = TestConfig
        .robolectric { sdk = 34 }
        .allure { epic("Shop") }
) {
    robolectricTestSuite<MySuiteContent>("on Android 14")
}

The session automatically keeps this integration's classes host-loaded (out of the Robolectric sandbox), so runtime steps and attachments recorded inside the sandbox reach the report. Only when you skip the session and wire an AllureExecutionReport onto individual suites instead, add the setting yourself:

.robolectric { portablePackages += "io.github.uoooo.testballoon.allure" }

testballoon-allure-android writes results on the device via TestStorage, so Gradle retrieves them to the host automatically.

// build.gradle.kts (Android module)
plugins {
    id("de.infix.testBalloon") version "<testballoon-version>"
}

android {
    defaultConfig {
        testInstrumentationRunnerArguments["useTestStorageService"] = "true"
    }
}

dependencies {
    androidTestImplementation("io.github.uoooo:testballoon-allure-android:<version>")
    androidTestUtil("androidx.test.services:test-services:<androidx-test-services-version>")
}

// androidTest source set — activates reporting for all instrumented TestBalloon tests:
class MyDeviceTestSession : AllureAndroidTestSession()

After connectedAndroidTest, results appear under build/outputs/connected_android_test_additional_output/<variant>/connected/<device>/allure-results.

Apache-2.0