Skip to main content
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 in entityLink, 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

string
required
Name of the test case. Must be unique within the target entity scope.
string
required
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.
array
Array of parameter name/value pairs as defined by the test definition.
string
Description of the test case in Markdown format.
string
Human-readable display name for the test case.
array
Array of reviewer references (users or teams). Each item accepts the same fields as owners.
boolean
Compute the passed and failed row count for the test case. Defaults to false.
boolean
Use dynamic assertion to evaluate the test case, if the test definition supports it. Defaults to false.
array
Names of the columns to group test results by. When set, the test runs overall and grouped by these columns. Defaults to [].
integer
Number of top dimension values to show before the rest are grouped as Others. Accepts 1 to 50. Defaults to 5.
string
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.
array
Array of owner references (users or teams) to assign.
POST /v1/dataQuality/testCases

Returns

Returns the created test case object with all specified properties and system-generated fields.

Response

string
Unique identifier for the test case (UUID format).
string
Test case name.
string
Fully qualified name in format table.column.testCaseName or table.testCaseName.
string
Description of the test case.
object
Reference to the test definition.
object
Reference to the test suite.
Entity link to the target table or column.
array
Parameter values for this test case.
array
List of owners assigned to the test case.
number
Version number for the entity (starts at 0.1).

Create or Update (PUT)

Use PUT /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 tableCustomSQLQuery test definition and carries the SQL itself in parameterValues. 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.
A test case passes values to a SQL-based test definition through 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-in tableCustomSQLQuery 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 sets testDefinition 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: threshold and thresholdUnit apply only if the test definition declares thresholdUnit. With ABSOLUTE, threshold is a row count. With PERCENTAGE, it is a share of the evaluated rows and can’t exceed 100. A negative or non-numeric threshold returns a 400 error.
  • Row counts: Set computePassedFailedRowCount to true to report passed and failed row counts.
For more information, see Create a Test Definition.

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 optionValues of 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 in entityLink must be one of them.
A request that fails either check returns 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.

Error Handling