Create a Test Case
Create a new test case instance applied to a specific table or column
POST
POST /v1/dataQuality/testCases
Create a Test Case
Create a new test case by linking a test definition to a specific table or column with concrete parameter values. The server associates the test case with the basic suite of the table inentityLink, creating that suite if needed. Omit testSuite from the create request. Automatically created suites are named <tableFQN>.testSuite. An existing basic suite keeps its name.
Body Parameters
Fully qualified name (FQN) of the test definition to use. For example,
columnValueMaxToBeBetween. For a custom SQL test (the Custom SQL Query test type in the UI), use tableCustomSQLQuery. For a test case on a custom test definition you created, use that definition’s name, such as columnValuesMaxLength. For more information, see Custom SQL Test Cases.Entity link to the target table or column. Format:
<#E::table::tableFQN> for table-level or <#E::table::tableFQN::columns::colName> for column-level.Use dynamic assertion to evaluate the test case, if the test definition supports it. Defaults to
false.Names of the columns to group test results by. When set, the test runs overall and grouped by these columns. Defaults to
[].Number of top dimension values to show before the rest are grouped as
Others. Accepts 1 to 50. Defaults to 5.Name of the data quality dimension for this test case. Defaults to the dimension of the test definition. Accepts a built-in dimension or any custom dimension registered in Settings > Preferences > Data Quality.
POST /v1/dataQuality/testCases
Returns
Returns the created test case object with all specified properties and system-generated fields.Response
Create or Update (PUT)
UsePUT /v1/dataQuality/testCases instead of POST to perform an upsert. If a test case with the same fullyQualifiedName already exists, the server updates it. Otherwise, the server creates a new test case. PUT accepts the same body parameters as POST, including the optional description field. Both curl examples include description.
PUT updates an existing entity instead of returning a 409 conflict error.
Custom SQL Test Cases
OpenMetadata has two ways to run SQL in a test case:- Custom SQL test: the Custom SQL Query test type in the UI. The test case uses the built-in
tableCustomSQLQuerytest definition and carries the SQL itself inparameterValues. You don’t create a test definition. - Custom test definition: a reusable SQL template you create once, with
{{ paramName }}placeholders. Test cases then reference it by name. For more information, see Test Cases for a Custom Test Definition.
parameterValues. The server rejects any parameter that the test definition doesn’t declare in parameterDefinition, and requires every parameter marked required.
Custom SQL Test
The built-intableCustomSQLQuery test definition runs a SQL query against a table. It accepts these parameters:
Test Cases for a Custom Test Definition
A test case for a custom SQL test definition setstestDefinition to the definition’s name and passes one parameterValues entry per {{ paramName }} placeholder. The following request uses a custom columnValuesMaxLength definition, which declares maxLength, threshold, and thresholdUnit:
- Pass condition: The test case passes when the number of rows the SQL returns is within the tolerance. With no
threshold, any returned row fails the test case. - Threshold:
thresholdandthresholdUnitapply only if the test definition declaresthresholdUnit. WithABSOLUTE,thresholdis a row count. WithPERCENTAGE, it is a share of the evaluated rows and can’t exceed100. A negative or non-numericthresholdreturns a400error. - Row counts: Set
computePassedFailedRowCounttotrueto report passed and failed row counts.
Parameter Validation
OpenMetadata checks a new test case against its test definition before it stores it:- Parameter values: Each value must be one of the
optionValuesof the matching parameter in the test definition. The comparison ignores case, and a blank value counts as not set. - Column data type: When the test definition lists
supportedDataTypes, the data type of the column inentityLinkmust be one of them.
400. POST /v1/dataQuality/testCases and POST /v1/dataQuality/testCases/createMany both apply the checks. createMany checks every test case before it stores any, so one rejected test case means none are stored.
An update checks only what it changes. A changed parameter value must be one of the options, and a test case moved to another column or test definition is checked in full. A test case stored before these checks, or one whose column changed data type later, stays editable.