Skip to main content

Test Runner

The TestRunner class provides a fluent API for executing data quality tests against tables cataloged in Collate. It automatically fetches table metadata and service connections, letting you run tests with minimal configuration. The TestRunner lets you:
  • Execute tests defined in code against cataloged tables.
  • Run tests previously configured in the Collate UI.
  • Load test definitions from YAML workflow files.
  • Validate data at the table and column levels.
  • Get detailed test results for programmatic handling.
Note: If you’re using Collate Cloud, TestRunner needs access to Collate’s SaaS-managed secrets manager to decrypt your connection credentials. For more information about how to set up secret credentials and troubleshoot issues, see Using External Secrets Managers.

Basic Usage

The following sections walk through each step of running a test, from creating a runner to processing results.

Creating a TestRunner

Create a runner for a specific table using its fully qualified name (FQN):
The table FQN format is: {service}.{database}.{schema}.{table}.

Adding Tests

Add test definitions to the runner:

Adding Multiple Tests

Use add_tests() to add several tests at once:

Running Tests

Execute all configured tests:

Complete Example

Here’s a complete example of testing a customer table:

Running Tests from Collate UI

Instead of defining tests in code, run tests that data stewards have configured in the Collate UI. This enables a collaborative workflow where:
  • Data stewards define and maintain test criteria in the UI.
  • Engineers execute those tests automatically in pipelines.
This approach ensures:
  • Test definitions stay synchronized with business requirements.
  • Engineers don’t need to modify code when test criteria change.
  • All stakeholders own data quality.

Customizing Test Metadata

Customize test names, display names, and descriptions:
Or pass values directly to the constructor:

Configuring Row Count Computation

Some tests support computing the number and percentage of rows that passed or failed:
This provides detailed metrics about test failures, useful for:
  • Identifying the scope of data quality issues.
  • Prioritizing remediation efforts.
  • Tracking data quality trends over time.

Test Runner Configuration

Customize the test runner behavior using the setup() method:

Configuration Parameters

The table below lists all parameters accepted by the setup() method.

Understanding Test Results

Test results contain detailed information about test execution:

Test Status Values

Each test result includes one of the following status values.
  • Success: Test passed all validation criteria.
  • Failed: Test did not meet validation criteria.
  • Aborted: Test execution was interrupted or could not complete.

Integration with ETL Workflows

Integrate TestRunner into your extract, transform, load (ETL) pipelines:

Error Handling

Handle potential errors gracefully:

Best Practices

Follow these guidelines to get the most out of the TestRunner API.
  • Use descriptive test names: Make test failures easy to understand.
  • Use UI-defined tests: Let data stewards define test criteria.
  • Handle results programmatically: Don’t just print—take action.
  • Use appropriate thresholds: Set realistic min/max values based on data patterns.
  • Combine table and column tests: Ensure both structural and content quality.

Secrets Managers

If your organization uses an external secrets manager for credential storage, TestRunner needs it configured before it can decrypt connection credentials. For more information about how to set up secret credentials and troubleshoot issues, see Using External Secrets Managers.

Next Steps

Once you have TestRunner working, explore these related guides.