https://docs.justcat.it/reference/outputs/ Recent content in Outputs on Hugo -- gohugo.io Wed, 19 Aug 2026 10:00:00 +0200 https://docs.justcat.it/reference/outputs/introduction/ Tue, 25 Jan 2022 14:40:56 +0100 https://docs.justcat.it/reference/outputs/introduction/ Without an Output setting a run leaves no record beyond the console and the log. With one, every test is written where the setting says — its result, message and timing, and the whole test definition (suite, name, description, data sources, queries, expectation, …), so an output can be read without the project file: Output: xlsx, json That line puts an Excel file and a JSON file into TestResults/ next to the project file after every run. https://docs.justcat.it/reference/outputs/overview/ Tue, 25 Jan 2022 14:40:56 +0100 https://docs.justcat.it/reference/outputs/overview/ Format Best for Written Linux JSON — json scripts and further automation in any language after the run yes YAML — yaml the same data as JSON, easier to read by eye after the run yes XLSX — xlsx sharing results with people; the one format every plan writes after the run needs libgdiplus JUnit — junit test reports in Azure DevOps, GitLab, GitHub Actions, Jenkins after the run yes TRX — trx test reports in Azure DevOps and Visual Studio after the run yes SQL Server · PostgreSQL · Oracle history and reporting on top of results one row per test, as it finishes yes · yes · untested The format token in the second column is what the Output setting takes — Output: json, junit. https://docs.justcat.it/reference/outputs/settings/ Tue, 25 Jan 2022 14:40:56 +0100 https://docs.justcat.it/reference/outputs/settings/ Outputs are requested in the project file under the root key Output (also Outputs). The key is a root setting like Threads — at the very beginning of the line, not inside a test or a data source. It takes one of two forms. Short form — formats only # A string: one or more format tokens, separated by commas. Each becomes a file with the default name in the default directory. https://docs.justcat.it/reference/outputs/properties/ Tue, 21 May 2024 14:40:56 +0100 https://docs.justcat.it/reference/outputs/properties/ The file formats write a fixed set of these fields — JSON and YAML all of them, XLSX its 22 columns, JUnit and TRX what their schemas have room for; see each format’s page. A database output is different: CAT reads the columns of the table (or the parameters of the procedure) you point it at and writes the fields whose names it recognizes, in any order, any subset. This table is the list of names it recognizes. https://docs.justcat.it/reference/outputs/json/ Tue, 25 Jan 2022 14:40:56 +0100 https://docs.justcat.it/reference/outputs/json/ When to use it # For anything that reads the results by program: a pipeline step that fails the build on a failed test, a script that mails someone when a suite’s pass rate drops, a job that loads results somewhere CAT has no output for. JSON is read natively by PowerShell, Python and every CI platform. It carries everything — the complete test definition included — so nothing has to be looked up in the project file afterwards. https://docs.justcat.it/reference/outputs/yaml/ Tue, 25 Jan 2022 14:40:56 +0100 https://docs.justcat.it/reference/outputs/yaml/ When to use it # When a person will open the file — to look at a failed test’s message, to diff two runs in a text editor, to keep a readable record next to the project — or when the consuming tool speaks YAML. Multi-line messages come out as readable blocks rather than \n-escaped strings. For automation, JSON has the wider library support; the content is identical. How to set it # Output: yaml writes TestResults/cat-test-results-{timestamp}. https://docs.justcat.it/reference/outputs/xlsx/ Tue, 25 Jan 2022 14:40:56 +0100 https://docs.justcat.it/reference/outputs/xlsx/ When to use it # For people: business users, analysts, a developer who wants to sort and filter the failures of last night’s run without writing a line of code. It is also the one output the Starter and Professional plans write, so it is where a trial starts. It is not for automation — the file is a rendering of the results, not a data feed; take JSON for that. https://docs.justcat.it/reference/outputs/junit/ Wed, 20 Sep 2023 14:40:56 +0100 https://docs.justcat.it/reference/outputs/junit/ When to use it # In a pipeline, when the platform should show the tests — green and red per test, the failure message on click, trend over runs — rather than a log. JUnit is the report format every CI platform reads: Azure DevOps (Publish Test Results, JUnit), GitLab (artifacts:reports:junit), GitHub Actions (reporter actions), Jenkins (JUnit plugin). It carries the result and the message of each test, not the full definition; keep JSON next to it when a step needs the data. https://docs.justcat.it/reference/outputs/trx/ Tue, 25 Jan 2022 14:40:56 +0100 https://docs.justcat.it/reference/outputs/trx/ When to use it # On Azure DevOps, when the results should appear on the pipeline’s Tests tab with the charts and the per-test detail — the Publish Test Results task reads .trx natively (testResultsFormat: VSTest). Also when someone opens results in Visual Studio or VS Code. Outside the Microsoft tooling the format is rarely read; use JUnit there. Like JUnit it carries result and message, not the full definition. https://docs.justcat.it/reference/outputs/database-outputs/ Fri, 21 Aug 2026 10:00:00 +0200 https://docs.justcat.it/reference/outputs/database-outputs/ When to use it # When results should be kept across runs and reported on — a history of pass rates, a dashboard in Power BI, an alert built on a query — or when something should happen the moment a test fails (a procedure can do anything the database lets it). A database output also has the rows of the tests that finished when a run is killed; a file output has nothing.