ReOrc docs
Get ReOrc
English
English
  • About ReOrc
  • Set up and deployment
    • Set up organization
    • Install ReOrc agent
  • Getting started
    • 1. Set up a connection
      • BigQuery setup
    • 2. Create a project
    • 3. Create data models
    • 4. Build models in console
    • 5. Set up a pipeline
  • Connections
    • Destinations
      • Google Service Account
    • Integrations
      • Slack
  • Data modeling
    • Overview
    • Sources
    • Models
      • Model schema
      • Model configurations
    • Jinja templating
      • Variables
      • Macros
    • Materialization
    • Data lineage
    • Data tests
      • Built-in generic tests
      • Custom generic tests
      • Singular tests
  • Semantic modeling
    • Overview
    • Data Modelling vs Semantic Layer
    • Cube
      • Custom Dimension
      • Custom Measure
        • Aggregation Function
        • SQL functions and operators
        • Calculating Period-over-Period Changes
      • Relationship
    • View
      • Primary Dimension
      • Add Shared Fields
    • Shared Fields
    • Integration
      • Guandata Integration
      • Looker Studio
  • Pipeline
    • Overview
    • Modeling pipeline
    • Advanced pipeline
    • Job
  • Health tracking
    • Pipeline health
    • Data quality
  • Data governance
    • Data protection
  • Asset management
    • Console
    • Metadata
    • Version history
    • Packages and dependencies
  • DATA SERVICE
    • Overview
    • Create & edit Data Service
    • Data preview & download
    • Data sharing API
    • Access control
  • AI-powered
    • Rein AI Copilot
  • Settings
    • Organization settings
    • Project settings
    • Profile settings
    • Roles and permissions
  • Platform Specific
    • Doris/SelectDB
Powered by GitBook
On this page
  • Create a custom generic test
  • Add a custom generic test
  1. Data modeling
  2. Data tests

Custom generic tests

Beyond built-in generic tests, you can write custom generic tests to cover complex testing scenarios.

At bottom, generic tests are Jinja macros that return failing rows. These tests are considered project-level assets and can be used across different models in your project.

To define a generic test, simply write a macro and wrap it within {% test %} {% endtest %} block. A generic test should accept one or both standard parameters:

  • model: The model or resource where the test is applied.

  • column_name: If the test validates assumptions about a specific column's data, include the column_name parameter.

Here's an example:

This payment_amount_reasonable test receives four parameters: the model, column name, minimum and maximum amounts. Inside, the validation logic is organized into a CTE (common table expression) that queries all the payment amounts not in the reasonable range.

We can apply this generic test to models that store payment amount of different kinds.

-- custom generic test for the reasonable payment amount

{% test payment_amount_reasonable(model, column_name, min_amount=0, max_amount=200) %}

with validation as (
    select
        {{ column_name }} as payment_amount
    from {{ model }}
    where {{ column_name }} < {{ min_amount }}
        or {{ column_name }} > {{ max_amount }}
)

select *
from validation

{% endtest %}

Create a custom generic test

To create a custom generic test, follow these steps:

  1. In your project, go to Library > Generic Test.

  2. Click + Add new.

  3. Define the generic test with the following fields:

    • SQL Code: provide the test code.

    • Parameter: hit the Refresh button to fetch the parameters involved in the test definition and provide the type.

    • Description: describe the functionality of the test.

    • Category: select the test category that the test should reflect.

  4. Click Add.

Add a custom generic test

The created generic test is then accessible from Test case template. You set up the test the same way as a built-in generic test.

Specify parameter values in the Configuration section:

  • Generic Test: Select the desired generic test from the dropdown menu.

  • Test Category: Assign an appropriate category to the test based on its nature.

  • Configuration: The test script will be automatically populated when you select a generic test from the dropdown.

  • Parameters: Provide the parameter values.

Once added, you can verify the test by running the model in Console.

PreviousBuilt-in generic testsNextSingular tests

Last updated 4 months ago