Katalon Studio has no native Allure adapter. Here's how to get one anyway.

JUnit has an official Allure adapter. TestNG has one. Cucumber has one. Katalon Studio does not, even though it's one of the most widely used test automation platforms out there. Allure-Katalon Bridge fixes that. It turns any Katalon Studio project into an Allure-reporting project by copying a handful of files into it. No plugin installation, no OSGi packaging, no command line required, and no changes to your existing Test Cases or Test Suites. - GitHub: https://github.com/montbaga/allure-katalon-bridge - npm: https://www.npmjs.com/package/allure-katalon-bridge - License: Apache-2.0 What you get, automatically Once it's installed, every test suite run produces: - One Allure result per test case, with status, timing, suite/host/thread labels, and the test framework identified as Katalon Studio - A failure screenshot on any non-passed WebUI test case (screenshot on every test case, pass or fail, is a one-line config change if you want it) - A stack trace attached automatically on failure - A stable history ID, so retries and repeat runs show up as trend data in the report instead of unrelated one-off results - A self-contained allure-report/ _ .html file, generated automatically at the end of the run. You double-click it and it opens, same as any other HTML file, because everything (styles, scripts, data) is embedded inline. No local server, noallure open , nothing extra to run. If you're running a Test Suite Collection, every member suite combines into a single report instead of one report per suite, and that report is named after the Collection itself. If the same suite runs more than once inside a Collection (once per browser, for example), each occurrence gets its own entry in the report rather than merging into one. A suite that opens a browser shows exactly which one right in its name in the Suites view; a suite that never opens one (a pure API test case, say) doesn't get a browser label at all. Step-level detail inside a test case is entirely opt-in, from a Test Case script or Cucumber glue code: CustomKeywords.'allure.AllureKeywords.step'('Log in as admin', { WebUI.setText(findTestObject('Page/input_Username'), 'admin') WebUI.click(findTestObject('Page/button_Login')) }) CustomKeywords.'allure.AllureKeywords.severity'('critical') CustomKeywords.'allure.AllureKeywords.epic'('Patient Management') CustomKeywords.'allure.AllureKeywords.attachJson'('Booking payload', responsePayload) Everything else, the zero-touch part, needs none of that. Steps, epics, and severities are extras for when you want more detail, not a requirement to get a working report. Installing it Pick whichever fits how you work: Double-click, the simplest path. Open the folder matching your OS, double-click the installer, pick your Katalon project folder in the dialog that opens. Uninstall the same way. Drag-and-drop: drop your project folder straight onto the installer file, skips the dialog entirely. Script, for CI or anyone scripting the setup: ./Linux/install.sh /path/to/your/katalon/project macOS shares this same script (bash is bash on both), and there's a Windows PowerShell equivalent too. npm, works identically on Windows, macOS, and Linux, no need to pick a platform-specific script at all: npx allure-katalon-bridge install "/path/to/your/katalon/project" or install it once and reuse it across projects: npm install -g allure-katalon-bridge allure-katalon-bridge install "/path/to/your/katalon/project" Re-running install on a project you've already set up upgrades it in place, no side effects. A customized allure.properties is left alone by default; add --force (or -Force on the PowerShell script) if you want it overwritten with the shipped default too. What actually lands in your project Test Listeners/AllureTestListener.groovy auto-discovered by Katalon, the only wiring needed Keywords/allure/AllureReportBridge.groovy the engine: status mapping, attachments, environment/executor/categories files Keywords/allure/AllureConfig.groovy allure.properties reader, with ALLURE_* env var overrides Keywords/allure/AllureKeywords.groovy optional: step(), attachText/Json/Html/File/Screenshot, epic/feature/story/severity/label/link/issue/tmsLink/parameter Include/config/allure/allure.properties configuration file (results dir, screenshot policy, and more) Include/config/allure/categories.json failure categorization tuned to Katalon/Selenium exception types Drivers/allure-java-commons-2.35.4.jar Apache-2.0, from Qameta Software Drivers/allure-model-2.35.4.jar the only 2 extra jars needed Drivers/fetch-allure-jars.ps1 re-downloads those 2 jars from Maven Central if your org won't commit binaries to git View Allure Report.bat / .command optional: opens your most recent report for you view-allure-report.sh same, for Linux/CI or manual use Everything it installs is tracked in .allure-bridge/manifest.txt , so uninstalling removes exactly what was added and touches nothing else in your project. allure-results/ (your generated test output) and your allure.properties are kept by default even after uninstall. Configuring it Everything lives in Include/config/allure/allure.properties , and any key can be overridden per environment with ALLURE_ (so allure.results.dir becomes ALLURE_RESULTS_DIR ), handy for pointing different CI environments at different result folders without touching the file itself. | Key | Default | What it does | |---|---|---| allure.enabled | true | Master switch | allure.results.dir | allure-results | Where raw results are written | allure.clean.results.before.run | true | Clears last run's results first, so a report only shows the run it's named after | allure.attach.screenshot.on.failure | true | Screenshot on any non-passed status | allure.attach.screenshot.always | false | Screenshot on every test case, pass or fail | allure.categories.file | Include/config/allure/categories.json | Failure categorization template | allure.auto.generate.report | true | Auto-runs allure generate after every suite | allure.report.dir | allure-report | Where the generated HTML report lands | allure.report.single.file | true | One self-contained .html file; set false for a folder instead, useful for very large suites | allure.commandline.path | auto-detected | Manual override if auto-detection can't find your allure install | CI, out of the box Ready-to-copy configs ship for Azure Pipelines, GitHub Actions, and GitLab CI. Copy the one matching your platform, fill in one line with your Test Suite or Collection path, add your Katalon API key as a secret, and push. executor.json auto-detects Jenkins, Azure Pipelines, GitHub Actions, and GitLab CI from each platform's own standard environment variables, so your Allure report header links back to the exact build that produced it, with zero configuration on your end. One flag worth calling out if you're setting this up yourself: --config -webui.autoUpdateDrivers=true . Hosted CI agents update their browsers automatically, and Katalon's bundled WebUI driver can fall behind that, so without this flag a suite can start failing with SessionNotCreatedException purely because the agent's browser moved past what the bundled driver supports. This flag tells Katalon to fetch a matching driver at run time instead. Requirements - Katalon Studio (built against long-stable public APIs, so it isn't pinned to one specific version) - Windows or macOS to use the double-click installer as-is; Linux works through the install script from a terminal - The Allure commandline ( npm install -g allure-commandline ) to auto-generate the HTML report and view it. The bridge auto-detects it across PATH, common install locations, and your login shell; if it still can't find it, one clear warning tells you exactly what to set Why it's built the way it is | Problem | How it's solved | |---|---| | No hook to drive Allure's lifecycle from Katalon | Katalon's public, documented Test Listener API (@BeforeTestSuite /@BeforeTestCase /@AfterTestCase /@AfterTestSuite ) | | Allure's Jackson clashes with Katalon's bundled Jackson | Ships only allure-java-commons and allure-model , whose Jackson is shaded internally | | Results land in a different folder depending on IDE vs CLI vs CI | Results directory is resolved explicitly against the project root, not the process's working directory | | A reporting bug could fail or change the outcome of a real test | Every hook catches its own exceptions and only logs a warning | | Can't afford to touch thousands of existing test cases | Fully automatic at the suite/case level; step-level detail is entirely opt-in | Get started npx allure-katalon-bridge install "/path/to/your/katalon/project" Reopen the project in Katalon Studio, run a test suite like you always do, and a finished report is already waiting for you in allure-report/ by the time it's done. No extra click, no extra script. If you run into a Katalon or CI combination that doesn't work, open an issue on the repo. Questions or help wiring this into a specific setup are welcome too. Top comments (0)