Database outputs

A database output inserts one row per test into a table, or calls a procedure per test, as each test finishes — the result and the test's definition. What SQL Server, PostgreSQL and Oracle share; the scripts are on each database's page.

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. It is not a file to hand someone; pair it with XLSX for that.

How to set it #

The target is a data source the project already defines; the output names it with Database and says where to write with Table or Procedure:

Data sources:
- Name: DWH
  Provider: SqlServer@2
  Connection string: "%DWH_CONNECTION_STRING%"

Output:
- Database: DWH
  Table: dbo.CatTestResult

Exactly one of Table and Procedure; neither, or both, fails the open. Not available on the Starter and Professional plans (MS Excel only).

What it looks like #

One row per test. The sample run in a table with the default columns, the wide ones abbreviated:

 ExecutionGuid  Project  FullName                                               TestResult  StartedOn                    RawMessage                                        Exception                            Expectation       ThreadNumber
 78084065-…     Flights  [Smoke tests].[Airline dimension matches the source]   Passed      2026-08-21 09:06:38.2510955  The sets match.                                   NULL                                 sets match        0
 78084065-…     Flights  [Data quality].[No booking without a passenger]        Failed      2026-08-21 09:06:38.3346170  No row was expected, but at least 1 row exists…   NULL                                 set is empty      0
 78084065-…     Flights  [Smoke tests].[Flights table is loaded]                Error       2026-08-21 09:06:38.4778644  Error when executing the test: Invalid object…    Invalid object name 'dbo.Flights'.   set is not empty  0

Details #

Columns are matched by name, not by position. Before the run CAT reads the columns of the table (or the parameters of the procedure) and maps every one whose name is on the Properties list — matched by naming convention, so TestResult, test_result and TEST_RESULT all work, and a parameter may carry the prefix C_. Columns it does not recognize are left alone; they must be nullable or have a default, or the insert fails. So the table may have three columns or thirty: drop what you do not need, add your own (with a prefix or suffix, so a future CAT column cannot collide).

Creates the objects when it may. A table that does not exist is created with every column; a procedure that does not exist is created together with its table (dbo.CatTestResult, public.cat_test_result, CAT_TEST_RESULT in the package’s schema). That needs CREATE permission on the schema — which a CAT account usually should not have; create the objects from the scripts on the database’s page and give CAT INSERT (or EXECUTE) only.

One row per test, as it finishes. Each execution thread keeps its own connection and its own prepared INSERT or CALL, so parallel runs write in parallel and a killed run leaves the rows written so far. The command is prepared once, before the first test — a table altered mid-run is not noticed until the next run.

The whole run shares one Execution Guid; a report groups by it. Started On and Finished On are UTC.

Related #

• SQL Server · PostgreSQL · Oracle — the scripts and each database’s specifics.
• Properties — the column names CAT recognizes.
• Settings — the Output key.