adding-dbt-unit-test

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Add unit test for a dbt model

为dbt模型添加单元测试

What are unit tests in dbt

dbt中的单元测试是什么

In software programming, unit tests validate small portions of your functional code, and they work much the same way in dbt. dbt unit tests allow you to validate your SQL modeling logic on a small set of static inputs before you materialize your full model in production. dbt unit tests enable test-driven development, benefiting developer efficiency and code reliability.

Unit tests allow enforcing that all the unit tests for a model pass before it is materialized (i.e. dbt won't materialize the model in the database if any of its unit tests do not pass).

在软件编程中，单元测试用于验证功能代码的小部分逻辑，在dbt中它们的作用方式基本相同。dbt单元测试允许你在生产环境中物化完整模型之前，通过一小组静态输入验证你的SQL建模逻辑。dbt单元测试支持测试驱动开发，有助于提升开发效率和代码可靠性。

单元测试可以强制要求：模型的所有单元测试通过后，才能对其进行物化（即，如果模型的任何单元测试未通过，dbt不会在数据库中物化该模型）。

When to use

适用场景

You should unit test a model:

Adding Model-Input-Output scenarios for the intended functionality of the model as well as edge cases to prevent regressions if the model logic is changed at a later date.
Verifying that a bug fix solves a bug report for an existing dbt model.

More examples:

When your SQL contains complex logic:
- Regex
- Date math
- Window functions
- ```
case when
```
  statements when there are many
```
when
```
  s
- Truncation
- Complex joins (multiple joins, self-joins, or joins with non-trivial conditions)
When you're writing custom logic to process input data, similar to creating a function.
Logic for which you had bugs reported before.
Edge cases not yet seen in your actual data that you want to be confident you are handling properly.
Prior to refactoring the transformation logic (especially if the refactor is significant).
Models with high "criticality" (public, contracted models or models directly upstream of an exposure).

你应该为以下场景的模型编写单元测试：

为模型的预期功能以及边缘情况添加“模型-输入-输出”场景，防止后续修改模型逻辑时出现回归问题。
验证bug修复是否解决了现有dbt模型的bug报告。

更多示例场景：

当你的SQL包含复杂逻辑时：
- 正则表达式（Regex）
- 日期运算（Date math）
- 窗口函数（Window functions）
- 包含多个
```
when
```
  条件的
```
case when
```
  语句
- 截断（Truncation）
- 复杂关联（多表关联、自关联或带有非平凡条件的关联）
当你编写自定义逻辑处理输入数据时（类似于创建函数）。
之前出现过bug报告的逻辑。
实际数据中尚未出现但你希望确保能正确处理的边缘情况。
重构转换逻辑之前（尤其是重大重构）。
高“关键性”的模型（公开模型、契约模型或直接位于暴露对象上游的模型）。

When not to use

不适用场景

Cases we don't recommend creating unit tests for:

Built-in functions that are tested extensively by the warehouse provider. If an unexpected issue arises, it's more likely a result of issues in the underlying data rather than the function itself. Therefore, fixture data in the unit test won't provide valuable information.
- common SQL spec functions like
```
min()
```
  , etc.

我们不建议为以下场景创建单元测试：

仓库提供商已进行大量测试的内置函数。如果出现意外问题，更可能是底层数据的问题而非函数本身。因此，单元测试中的测试数据无法提供有价值的信息。
- 常见SQL规范函数如
```
min()
```
  等。

General format

通用格式

dbt unit test uses a trio of the model, given inputs, and expected outputs (Model-Inputs-Outputs):

```
model
```
- when building this model
```
given
```
inputs - given a set of source, seeds, and models as preconditions
```
expect
```
output - then expect this row content of the model as a postcondition

dbt单元测试由三部分组成：模型、给定输入和预期输出（模型-输入-输出）：

```
model
```
- 要测试的目标模型
```
given
```
输入 - 给定作为前置条件的源、种子和模型集合
```
expect
```
输出 - 预期模型生成的行内容作为后置条件

Workflow

工作流程

1. Choose the model to test

1. 选择要测试的模型

Self explanatory -- the title says it all!

不言自明——标题已经说明一切！

2. Mock the inputs

2. 模拟输入

Create an input for each of the nodes the model depends on.
Specify the mock data it should use.
Specify the
```
format
```
if different than the default (YAML
```
dict
```
).
- See the "Data
```
format
```
  s for unit tests" section below to determine which
```
format
```
  to use.
The mock data only needs include the subset of columns used within this test case.

Tip: Use

dbt show

to explore existing data from upstream models or sources. This helps you understand realistic input structures. However, always sanitize the sample data to remove any sensitive or PII information before using it in your unit test fixtures.

shell

undefined

为模型依赖的每个节点创建输入。
指定要使用的模拟数据。
如果与默认格式（YAML
```
dict
```
）不同，需指定
```
format
```
。
- 请查看下方“单元测试的数据
```
format
```
  ”部分，确定要使用的
```
format
```
  。
模拟数据只需包含该测试用例中用到的列子集。

提示： 使用

dbt show

探索上游模型或源的现有数据，这有助于你了解真实的输入结构。但在将样本数据用于单元测试测试数据之前，务必清理数据以移除任何敏感或PII信息。

shell

undefined

Preview upstream model data

预览上游模型数据

dbt show --select upstream_model --limit 5

undefined

dbt show --select upstream_model --limit 5

undefined

3. Mock the output

3. 模拟输出

Specify the data that you expect the model to create given those inputs.
Specify the
```
format
```
if different than the default (YAML
```
dict
```
).
- See the "Data
```
format
```
  s for unit tests" section below to determine which
```
format
```
  to use.
The mock data only needs include the subset of columns used within this test case.

指定给定输入下，预期模型生成的数据。
如果与默认格式（YAML
```
dict
```
）不同，需指定
```
format
```
。
- 请查看下方“单元测试的数据
```
format
```
  ”部分，确定要使用的
```
format
```
  。
模拟数据只需包含该测试用例中用到的列子集。

Minimal unit test

最简单元测试

Suppose you have this model:

sql

-- models/hello_world.sql

select 'world' as hello

Minimal unit test for that model:

yaml

undefined

假设你有如下模型：

sql

-- models/hello_world.sql

select 'world' as hello

该模型的最简单元测试：

yaml

undefined

models/_properties.yml

unit_tests:

name: test_hello_world

Always only one transformation to test

model: hello_world

No inputs needed this time!

Most unit tests will have inputs -- see the "real world example" section below

given: []

Expected output can have zero to many rows

expect: rows: - {hello: world}

undefined

unit_tests:

name: test_hello_world

每次仅测试一个转换逻辑

model: hello_world

本次不需要输入！

大多数单元测试会包含输入——请查看下方“真实场景示例”部分

given: []

预期输出可以包含0到多行

expect: rows: - {hello: world}

undefined

Executing unit tests

执行单元测试

Run the unit tests, build the model, and run the data tests for the

hello_world

model:

shell

dbt build --select hello_world

This saves on warehouse spend as the model will only be materialized and move on to the data tests if the unit tests pass successfully.

Or only run the unit tests without building the model or running the data tests:

shell

dbt test --select "hello_world,test_type:unit"

Or choose a specific unit test by name:

shell

dbt test --select test_is_valid_email_address

运行单元测试、构建模型并为

hello_world

模型运行数据测试：

shell

dbt build --select hello_world

这样可以节省仓库资源，因为只有单元测试通过后，模型才会被物化并继续执行数据测试。

或者仅运行单元测试，不构建模型或执行数据测试：

shell

dbt test --select "hello_world,test_type:unit"

或者按名称选择特定的单元测试：

shell

dbt test --select test_is_valid_email_address

Excluding unit tests from production builds

从生产构建中排除单元测试

dbt Labs strongly recommends only running unit tests in development or CI environments. Since the inputs of the unit tests are static, there's no need to use additional compute cycles running them in production. Use them when doing development for a test-driven approach and CI to ensure changes don't break them.

Use the

--resource-type

flag

--exclude-resource-type

or the

DBT_EXCLUDE_RESOURCE_TYPES

environment variable to exclude unit tests from your production builds and save compute.

dbt Labs强烈建议仅在开发或CI环境中运行单元测试。由于单元测试的输入是静态的，无需在生产环境中消耗额外计算资源运行它们。在开发中使用它们践行测试驱动开发，在CI中确保变更不会破坏它们。

使用

--resource-type

标志、

--exclude-resource-type

或

DBT_EXCLUDE_RESOURCE_TYPES

环境变量，从生产构建中排除单元测试以节省计算资源。

More realistic example

更贴近真实的示例

yaml

unit_tests:

  - name: test_order_items_count_drink_items_with_zero_drinks
    description: >
      Scenario: Order without any drinks
        When the `order_items_summary` table is built
        Given an order with nothing but 1 food item
        Then the count of drink items is 0

    # Model
    model: order_items_summary

    # Inputs
    given:
      - input: ref('order_items')
        rows:
          - {
              order_id: 76,
              order_item_id: 3,
              is_drink_item: false,
            }
      - input: ref('stg_orders')
        rows:
          - { order_id: 76 }

    # Output
    expect:
      rows:
        - {
            order_id: 76,
            count_drink_items: 0,
          }

For more examples of unit tests, see references/examples.md

yaml

unit_tests:

  - name: test_order_items_count_drink_items_with_zero_drinks
    description: >
      场景：不含饮品的订单
        当构建`order_items_summary`表时
        给定一个仅包含1个食品项的订单
        则饮品项的计数为0

    # 模型
    model: order_items_summary

    # 输入
    given:
      - input: ref('order_items')
        rows:
          - {
              order_id: 76,
              order_item_id: 3,
              is_drink_item: false,
            }
      - input: ref('stg_orders')
        rows:
          - { order_id: 76 }

    # 输出
    expect:
      rows:
        - {
            order_id: 76,
            count_drink_items: 0,
          }

如需更多单元测试示例，请查看references/examples.md

Supported and unsupported scenarios

支持与不支持的场景

dbt only supports unit testing SQL models.
- Unit testing Python models is not supported.
- Unit testing non-model nodes like snapshots, seeds, sources, analyses, etc. is not supported.
dbt only supports adding unit tests to models in your current project.
- Unit testing cross-project models or models imported from a package is not supported.
dbt does not support unit testing models that use the
```
materialized view
```
materialization.
dbt does not support unit testing models that use recursive SQL.
dbt does not support unit testing models that use introspective queries.
dbt does not support an
```
expect
```
output for final state of the database table after inserting/merging for incremental models.
dbt does support an
```
expect
```
output for what will be merged/inserted for incremental models.

dbt仅支持为SQL模型编写单元测试。
- 不支持为Python模型编写单元测试。
- 不支持为非模型节点（如快照、种子、源、分析等）编写单元测试。
dbt仅支持为当前项目中的模型添加单元测试。
- 不支持为跨项目模型或从包中导入的模型编写单元测试。
dbt不支持为使用
```
materialized view
```
物化方式的模型编写单元测试。
dbt不支持为使用递归SQL的模型编写单元测试。
dbt不支持为使用自省查询的模型编写单元测试。
dbt不支持为增量模型的数据库表插入/合并后的最终状态指定
```
expect
```
输出。
dbt支持为增量模型的待合并/插入数据指定
```
expect
```
输出。

Handy to know

实用提示

Unit tests must be defined in a YAML file in your
```
model-paths
```
directory (
```
models/
```
by default)
Fixture files for unit tests must be defined in a SQL or CSV file in your
```
test-paths
```
directory (
```
tests/fixtures
```
by default)
Include all
```
ref
```
or
```
source
```
model references in the unit test configuration as
```
input
```
s to avoid "node not found" errors during compilation.
If your model has multiple versions, by default the unit test will run on all versions of your model.
If you want to unit test a model that depends on an ephemeral model, you must use
```
format: sql
```
for the ephemeral model input.
Table names within the model must be aliased in order to unit test
```
join
```
logic

单元测试必须定义在
```
model-paths
```
目录（默认为
```
models/
```
）下的YAML文件中
单元测试的测试数据文件必须定义在
```
test-paths
```
目录（默认为
```
tests/fixtures
```
）下的SQL或CSV文件中
在单元测试配置中，需将所有
```
ref
```
或
```
source
```
模型引用作为
```
input
```
包含在内，以避免编译时出现“节点未找到”错误。
如果你的模型有多个版本，默认情况下单元测试会在模型的所有版本上运行。
如果你要为依赖临时模型（ephemeral model）的模型编写单元测试，必须为临时模型输入使用
```
format: sql
```
。
要为关联逻辑编写单元测试，模型中的表必须设置别名

YAML for specifying unit tests

用于指定单元测试的YAML

For all the required and optional keys in the YAML definition of unit tests, see references/spec.md

关于单元测试YAML定义中的所有必填和可选键，请查看references/spec.md

Inputs for unit tests

单元测试的输入

Use

input

s in your unit tests to reference a specific model or source for the test:

For

input:

, use a string that represents a

ref

source

call:

ref('my_model')

ref('my_model', v='2')

ref('dougs_project', 'users')

```
source('source_schema', 'source_name')
```

For seed inputs:
- If you do not supply an input for a seed, we will use the seed's CSV file as the input.
- If you do supply an input for a seed, we will use that input instead.
Use “empty” inputs by setting rows to an empty list
```
rows: []
```
- This is useful if the model has a
```
ref
```
  or
```
source
```
  dependency, but its values are irrelevant to this particular unit test. Just beware if the model has a join on that input that would cause rows to drop out!

models/schema.yml

yaml

unit_tests:
  - name: test_is_valid_email_address  # this is the unique name of the test
    model: dim_customers  # name of the model I'm unit testing
    given:  # the mock data for your inputs
      - input: ref('stg_customers')
        rows:
         - {email: cool@example.com,     email_top_level_domain: example.com}
         - {email: cool@unknown.com,     email_top_level_domain: unknown.com}
         - {email: badgmail.com,         email_top_level_domain: gmail.com}
         - {email: missingdot@gmailcom,  email_top_level_domain: gmail.com}
      - input: ref('top_level_email_domains')
        rows:
         - {tld: example.com}
         - {tld: gmail.com}
      - input: ref('irrelevant_dependency')  # dependency that we need to acknowlege, but does not need any data
        rows: []
...

在单元测试中使用

input

来引用测试的特定模型或源：

对于

input:

，使用代表

ref

或

source

调用的字符串：

ref('my_model')

或

ref('my_model', v='2')

或

ref('dougs_project', 'users')

```
source('source_schema', 'source_name')
```

对于种子输入：
- 如果你不为种子提供输入，我们会将种子的CSV文件作为输入使用。
- 如果你为种子提供了输入，我们会使用该输入替代原种子文件。
通过设置
```
rows: []
```
来使用“空”输入
- 如果模型依赖某个
```
ref
```
  或
```
source
```
  ，但该依赖的值对当前测试用例无关紧要，这会很有用。但要注意，如果模型对该输入有关联操作，可能会导致行被过滤掉！

models/schema.yml

yaml

unit_tests:
  - name: test_is_valid_email_address  # 测试的唯一名称
    model: dim_customers  # 要进行单元测试的模型名称
    given:  # 输入的模拟数据
      - input: ref('stg_customers')
        rows:
         - {email: cool@example.com,     email_top_level_domain: example.com}
         - {email: cool@unknown.com,     email_top_level_domain: unknown.com}
         - {email: badgmail.com,         email_top_level_domain: gmail.com}
         - {email: missingdot@gmailcom,  email_top_level_domain: gmail.com}
      - input: ref('top_level_email_domains')
        rows:
         - {tld: example.com}
         - {tld: gmail.com}
      - input: ref('irrelevant_dependency')  # 需要声明但无需数据的依赖
        rows: []
...

Data

format

s for unit tests

单元测试的数据

format

dbt supports three formats for mock data within unit tests:

```
dict
```
(default): Inline YAML dictionary values.
```
csv
```
: Inline CSV values or a CSV file.
```
sql
```
: Inline SQL query or a SQL file.

To see examples of each of the formats, see references/examples.md

dbt支持在单元测试中使用三种模拟数据格式：

```
dict
```
（默认）：内联YAML字典值。
```
csv
```
：内联CSV值或CSV文件。
```
sql
```
：内联SQL查询或SQL文件。

如需查看每种格式的示例，请查看references/examples.md

How to choose the

format

如何选择

format

Use the
```
dict
```
format by default, but fall back to another format as-needed.
Use the
```
sql
```
format when testing a model that depends on an
```
ephemeral
```
model
Use the
```
sql
```
format when unit testing a column whose data type is not supported by the
```
dict
```
or
```
csv
```
formats.
Use the
```
csv
```
or
```
sql
```
formats when using a fixture file. Default to
```
csv
```
, but fallback to
```
sql
```
if any of the column data types are not supported by the
```
csv
```
format.
The
```
sql
```
format is the least readable and requires suppling mock data for all columns, so prefer other formats when possible. But it is also the most flexible, and should be used as the fallback in scenarios where
```
dict
```
or
```
csv
```
won't work.

Notes:

For the
```
sql
```
format you must supply mock data for all columns whereas
```
dict
```
and
```
csv
```
may supply only a subset.
Only the
```
sql
```
format allows you to unit test a model that depends on an ephemeral model --
```
dict
```
and
```
csv
```
can't be used in that case.
There are no formats that support Jinja.

默认使用
```
dict
```
格式，必要时再切换为其他格式。
当测试依赖临时模型（ephemeral model）的模型时，使用
```
sql
```
格式
当为
```
dict
```
或
```
csv
```
格式不支持的数据类型的列编写单元测试时，使用
```
sql
```
格式。
当使用测试数据文件时，使用
```
csv
```
或
```
sql
```
格式。默认使用
```
csv
```
，如果有列的数据类型不被
```
csv
```
格式支持，则切换为
```
sql
```
。
```
sql
```
格式的可读性最差，且需要为所有列提供模拟数据，因此尽可能优先使用其他格式。但它也是最灵活的，在
```
dict
```
或
```
csv
```
无法满足需求的场景中，可作为备选方案。

注意：

对于
```
sql
```
格式，你必须为所有列提供模拟数据，而
```
dict
```
和
```
csv
```
格式只需提供列的子集。
只有
```
sql
```
格式允许为依赖临时模型的模型编写单元测试——
```
dict
```
和
```
csv
```
格式无法用于该场景。
没有支持Jinja的格式。

Fixture files

测试数据文件

The

dict

format only supports inline YAML mock data, but you can also use

csv

sql

either inline or in a separate fixture file. Store your fixture files in a

fixtures

subdirectory in any of your

test-paths

. For example,

tests/fixtures/my_unit_test_fixture.sql

When using the

dict

csv

format, you only have to define the mock data for the columns relevant to you. This enables you to write succinct and specific unit tests. For the

sql

format all columns need to be defined.

dict

格式仅支持内联YAML模拟数据，但你也可以使用

csv

或

sql

格式的内联数据或单独的测试数据文件。将测试数据文件存储在任意

test-paths

下的

fixtures

子目录中，例如

tests/fixtures/my_unit_test_fixture.sql

。

使用

dict

或

csv

格式时，你只需定义与测试相关的列的模拟数据。这能让你编写简洁且针对性强的单元测试。而

sql

格式需要定义所有列。

Special cases

特殊场景

Unit testing incremental models. See references/special-cases-incremental-model.md.
Unit testing a model that depends on ephemeral model(s). See references/special-cases-ephemeral-dependency.md.
Unit test a model that depends on any introspective macros, project variables, or environment variables. See references/special-cases-special-case-overrides.md.
Unit testing versioned SQL models. See references/special-cases-versioned-model.md.

增量模型的单元测试。请查看references/special-cases-incremental-model.md。
依赖临时模型的模型的单元测试。请查看references/special-cases-ephemeral-dependency.md。
依赖自省宏、项目变量或环境变量的模型的单元测试。请查看references/special-cases-special-case-overrides.md。
版本化SQL模型的单元测试。请查看references/special-cases-versioned-model.md。

Platform/adapter-specific caveats

平台/适配器特定注意事项

There are platform-specific details required if implementing on (Redshift, BigQuery, etc). Read the caveats file for your database (if it exists):

references/warehouse-bigquery-caveats.md
references/warehouse-redshift-caveats.md

如果在（Redshift、BigQuery等）平台上实施，有特定的平台细节需要注意。请查看对应数据库的注意事项文件（如果存在）：

references/warehouse-bigquery-caveats.md
references/warehouse-redshift-caveats.md

Platform/adapter-specific data types

平台/适配器特定数据类型

Unit tests are designed to test for the expected values, not for the data types themselves. dbt takes the value you provide and attempts to cast it to the data type as inferred from the input and output models.

How you specify input and expected values in your unit test YAML definitions are largely consistent across data warehouses, with some variation for more complex data types.

Read the data types file for your database:

references/warehouse-bigquery-data-types.md
references/warehouse-postgres-data-types.md
references/warehouse-redshift-data-types.md
references/warehouse-snowflake-data-types.md
references/warehouse-spark-data-types.md

单元测试旨在测试预期的值，而非数据类型本身。dbt会获取你提供的值，并尝试将其转换为从输入和输出模型推断出的数据类型。

在单元测试YAML定义中指定输入和预期值的方式，在各数据仓库中基本一致，但对于更复杂的数据类型会有一些差异。

请查看对应数据库的数据类型文件：

references/warehouse-bigquery-data-types.md
references/warehouse-postgres-data-types.md
references/warehouse-redshift-data-types.md
references/warehouse-snowflake-data-types.md
references/warehouse-spark-data-types.md

Disabling a unit test

禁用单元测试

By default, all specified unit tests are enabled and will be included according to the

--select

flag.

To disable a unit test from being executed, set:

yaml

    config: 
      enabled: false

This is helpful if a unit test is incorrectly failing and it needs to be disabled until it is fixed.

默认情况下，所有指定的单元测试均已启用，并会根据

--select

标志被包含在内。

要禁用某个单元测试的执行，设置：

yaml

    config: 
      enabled: false

当单元测试出现错误失败且需要在修复前禁用时，这会很有帮助。

When a unit test fails

单元测试失败时

When a unit test fails, there will be a log message of "actual differs from expected", and it will show a "data diff" between the two:

actual differs from expected:

@@ ,email           ,is_valid_email_address
→  ,cool@example.com,True→False
   ,cool@unknown.com,False

There are two main possibilities when a unit test fails:

There was an error in the way the unit test was constructed (false positive)
There is an bug is the model (true positive)

It takes expert judgement to determine one from the other.

当单元测试失败时，会出现日志消息“actual differs from expected”，并显示两者之间的“数据差异”：

actual differs from expected:

@@ ,email           ,is_valid_email_address
→  ,cool@example.com,True→False
   ,cool@unknown.com,False

单元测试失败主要有两种可能：

单元测试的构建存在错误（假阳性）
模型存在bug（真阳性）

需要专业判断来区分这两种情况。

The

--empty

flag

--empty

标志

The direct parents of the model that you’re unit testing need to exist in the warehouse before you can execute the unit test. The

run

and

build

commands supports the

--empty

flag for building schema-only dry runs. The

--empty

flag limits the

ref

s and

sources

to zero rows. dbt will still execute the model SQL against the target data warehouse but will avoid expensive reads of input data. This validates dependencies and ensures your models will build properly.

Use the

--empty

flag to build an empty version of the models to save warehouse spend.

bash


dbt run --select "stg_customers top_level_email_domains" --empty

在执行单元测试之前，你要测试的模型的直接父节点必须存在于仓库中。

run

和

build

命令支持

--empty

标志来构建仅包含 schema 的空运行。

--empty

标志会将

ref

和

source

限制为0行。dbt仍会在目标数据仓库上执行模型SQL，但会避免读取输入数据的昂贵操作。这能验证依赖关系并确保模型可以正常构建。

使用

--empty

标志构建模型的空版本以节省仓库资源。

bash


dbt run --select "stg_customers top_level_email_domains" --empty

Common Mistakes

常见错误

Mistake	Fix
Testing simple SQL using built-in functions	Only unit test complex logic: regex, date math, window functions, multi-condition case statements
Mocking all columns in input data	Only include columns relevant to the test case
Using `sql` format when `dict` works	Prefer `dict` (most readable), fall back to `csv` or `sql` only when needed
Missing `input` for a `ref` or `source`	Include all model dependencies to avoid "node not found" errors
Testing Python models or snapshots	Unit tests only support SQL models

错误	修复方法
为使用内置函数的简单SQL编写测试	仅为复杂逻辑编写单元测试：正则表达式、日期运算、窗口函数、多条件case语句
为输入数据模拟所有列	仅包含与测试用例相关的列
在 `dict` 格式可用时使用 `sql` 格式	优先使用 `dict` （可读性最强），仅在必要时使用 `csv` 或 `sql`
遗漏 `ref` 或 `source` 对应的 `input`	包含所有模型依赖以避免“节点未找到”错误
为Python模型或快照编写测试	单元测试仅支持SQL模型

Similar testing concepts

类似的测试概念

There are similar concepts that dbt's

model

given

expect

lines up with (Hoare triple, Arrange-Act-Assert, Gherkin, What's in a Story?, etc):

dbt unit test	Description	Hoare triple	Arrange-Act-Assert	Gherkin	What's in a Story?
`model`	when running the command for this model	Command	Act	When	Event
`given`	given these test inputs as preconditions	Precondition	Arrange	Given	Givens
`expect`	then expect this output as a postcondition	Postcondition	Assert	Then	Outcome

dbt的

model

、

given

、

expect

与一些类似概念（霍尔三元组、Arrange-Act-Assert、Gherkin、用户故事要素等）相对应：

dbt单元测试	描述	霍尔三元组	Arrange-Act-Assert	Gherkin	用户故事要素
`model`	运行该模型的命令时	命令	Act（执行）	When（当）	事件
`given`	给定这些测试输入作为前置条件	前置条件	Arrange（准备）	Given（给定）	前置条件
`expect`	预期此输出作为后置条件	后置条件	Assert（断言）	Then（则）	结果

adding-dbt-unit-test

Original

Translation

Add unit test for a dbt model

为dbt模型添加单元测试

What are unit tests in dbt

dbt中的单元测试是什么

When to use

适用场景

When not to use

不适用场景

General format

通用格式

Workflow

工作流程

1. Choose the model to test

1. 选择要测试的模型

2. Mock the inputs

2. 模拟输入

Preview upstream model data

预览上游模型数据

3. Mock the output

3. 模拟输出

Minimal unit test

最简单元测试

models/_properties.yml

models/_properties.yml

Always only one transformation to test

No inputs needed this time!

Most unit tests will have inputs -- see the "real world example" section below

Expected output can have zero to many rows

每次仅测试一个转换逻辑

本次不需要输入！

大多数单元测试会包含输入——请查看下方“真实场景示例”部分

预期输出可以包含0到多行

Executing unit tests

执行单元测试

Excluding unit tests from production builds

从生产构建中排除单元测试

More realistic example

更贴近真实的示例

Supported and unsupported scenarios

支持与不支持的场景

Handy to know

实用提示

YAML for specifying unit tests

用于指定单元测试的YAML

Inputs for unit tests

单元测试的输入

Data formats for unit tests

单元测试的数据format

How to choose the format

如何选择format

Fixture files

测试数据文件

Special cases

特殊场景

Platform/adapter-specific caveats

平台/适配器特定注意事项

Platform/adapter-specific data types

平台/适配器特定数据类型

Disabling a unit test

禁用单元测试

When a unit test fails

单元测试失败时

The --empty flag

--empty标志

Common Mistakes

常见错误

Similar testing concepts

类似的测试概念

Data
`format`
s for unit tests

单元测试的数据
`format`

How to choose the
`format`

如何选择
`format`

The
`--empty`
flag

`--empty`
标志