Create a Test Definition
Create a custom test definition for data quality validation
POST
POST /v1/dataQuality/testDefinitions
Create a Test Definition
Create a custom test definition to define organization-specific data quality validation logic.Body Parameters
string
required
Name of the test definition. Must be unique across all test definitions.
string
Human-readable display name for the test definition.
string
Description of what this test validates, in Markdown format.
string
required
The entity type this test targets:
TABLE or COLUMN.array
required
Array of supported test platforms. Typically
["OpenMetadata"].array
Array of data types this test can be applied to, for example
STRING, INT, DOUBLE, VARCHAR, CHAR, TEXT, NUMBER, FLOAT, BOOLEAN. Only applicable when entityType is COLUMN.array
Array of parameter definitions that this test accepts.
string
SQL template for custom SQL-based test definitions. OpenMetadata renders the template with Jinja2, so every placeholder must use double curly braces:
{{ table_name }}: the table the test case runs against.{{ column_name }}: the column the test case runs against. Available only whenentityTypeisCOLUMN.{{ paramName }}: the value of a parameter declared inparameterDefinition.
table_name is reserved for all definitions, and column_name is also reserved when entityType is COLUMN. Don’t use reserved names as parameter names. For more information, see Custom SQL Test Definitions.string
Class name of the validator that runs the test. For a custom SQL test definition, set one of the following values. The OpenMetadata UI sets the same values when you create a custom SQL test definition:
ColumnRuleLibrarySqlExpressionValidator: use whenentityTypeisCOLUMN.TableRuleLibrarySqlExpressionValidator: use whenentityTypeisTABLE.
string
Data quality dimension the test belongs to:
Completeness, Accuracy, Consistency, Validity, Uniqueness, Integrity, SQL, or NoDimension.array
Names of the services this test definition supports. When empty, all services are supported. Defaults to
[].array
Fully qualified names of the domains the test definition belongs to.
array
Array of owner references (users or teams) to assign.
POST /v1/dataQuality/testDefinitions
Returns
Returns the created test definition object with all specified properties and system-generated fields.Response
string
Unique identifier for the test definition (UUID format).
string
Test definition name.
string
Fully qualified name (same as name for test definitions).
string
Human-readable display name.
string
Description of what the test validates.
string
Target entity type:
TABLE or COLUMN.array
Supported test platforms.
array
Data types this test can be applied to.
array
Parameters accepted by this test definition.
string
SQL template for custom SQL-based test definitions.
string
Validator that runs the test.
string
Data quality dimension the test belongs to.
string
Always
user for custom test definitions.number
Version number for the entity (starts at 0.1).
Custom SQL Test Definitions
A custom test definition is a reusable SQL template. To run a one-off SQL query on a single table, such as the Custom SQL Query test type in the UI, create a test case with the built-intableCustomSQLQuery definition instead. For more information, see Custom SQL Test Cases.
To create a test definition that runs your own SQL, set sqlExpression and declare every {{ paramName }} placeholder in parameterDefinition. The following request creates a column-level test that fails when any value in the column is longer than a limit:
- Pass condition: The test case passes only when the rendered query returns 0 rows. Write the query so that it returns the rows that violate the rule.
- Reserved names:
table_nameis reserved for table-level definitions.table_nameandcolumn_nameare reserved for column-level definitions. Do not declare them inparameterDefinition, because the validator supplies their values at runtime. - Parameters: A test case supplies values for
{{ paramName }}throughparameterValues. For more information, see Create a Test Case.
Create or Update (PUT)
UsePUT /v1/dataQuality/testDefinitions instead of POST to perform an upsert. If a test definition with the same name already exists, it will be updated; otherwise, a new test definition is created. The request body is the same as POST.
PUT will not return a 409 conflict error if the entity already exists. It will update the existing entity instead.