如何在dbt测试中正确传递--depends_on依赖声明

方案1：在测试配置中显式声明依赖 #

直接在tests.yml的测试条目下添加depends_on配置，指定宏中引用的所有模型。这样dbt无需通过宏的静态分析推断依赖，直接明确依赖关系，多依赖场景下配置也足够简洁。

示例配置：

models:
  - name: your_silver_model
    tests:
      - expect_column_int_sum_to_equal_other_table:
          column_name: target_column
          other_table: your_bronze_table
          derived_table: "{{ alpha_art_creation_proposal_status_history() }}"
          depends_on:
            - ref('alpha_order_item_briefing')
            # 如有其他依赖，直接追加即可

方案2：重构宏，让ref可被静态分析 #

将宏中条件块内的ref调用移到条件块外，用变量存储引用结果，再在条件逻辑中使用该变量。dbt的静态依赖分析能识别到条件块外的ref声明，从而正确推断依赖。

示例宏重构：

{% macro alpha_art_creation_proposal_status_history() %}
    -- 将ref移到条件块外，让dbt静态分析能捕获
    {% set order_item_briefing = ref('alpha_order_item_briefing') %}

    {% if some_condition %}
        SELECT * FROM {{ order_item_briefing }} WHERE status = 'proposed'
    {% else %}
        SELECT * FROM {{ order_item_briefing }} WHERE status = 'approved'
    {% endif %}
{% endmacro %}

方案3：使用显式依赖注册宏（适用于复杂动态场景） #

如果宏的依赖是动态生成的，可以用dbt_utils.generate_dependency宏显式注册依赖，强制dbt识别。该方案仅推荐用于动态依赖的特殊场景。

示例：

{% macro alpha_art_creation_proposal_status_history() %}
    {{ dbt_utils.generate_dependency(ref('alpha_order_item_briefing')) }}

    {% if some_condition %}
        SELECT * FROM {{ ref('alpha_order_item_briefing') }} WHERE status = 'proposed'
    {% else %}
        SELECT * FROM {{ ref('alpha_order_item_briefing') }} WHERE status = 'approved'
    {% endif %}
{% endmacro %}

方案对比 #

• 方案1最简洁，无需修改宏代码，仅通过测试配置声明依赖，多依赖场景只需追加列表项。
• 方案2需要调整宏结构，但能从根源上让dbt自动识别依赖，适合需要复用宏的场景。
• 方案3仅针对动态依赖的复杂场景，一般优先选择方案1或2。

内容的提问来源于stack exchange，提问作者Guilherme Noronha