dbt models with no tests

This rule flags every dbt model with no data test and no unit test attached to it. Either kind counts when the manifest links it to the model.

An untested model fails silently. A wrong join or a duplicated row flows downstream until someone questions a number. We rate the finding higher on a final model in a marts folder, because those feed dashboards directly.

Put a test floor on every model. Start with a floor: a uniqueness test on the grain and not_null on the key columns. Add relationship or accepted-values tests where a wrong value would mislead. Before dbt 1.8 the key is tests: rather than data_tests:.

Before:

models:
  - name: fct_orders
    description: One row per order.

After:

models:
  - name: fct_orders
    description: One row per order.
    columns:
      - name: order_id
        data_tests:
          - unique
          - not_null

A model that nothing reads yet, or one on its way to deletion. A thin staging model that only renames columns can also rely on the tests one layer down, if those cover the same keys. Write the reason in the model's description, so the next reader sees a decision rather than a gap.

manifest.json alone, which dbt parse writes. If the manifest holds no tests at all, we still report the finding, at medium confidence. A manifest built without its tests looks the same as a project that has none.

dbt_project_evaluator, rule fct_test_coverage. Ours checks the same concern, tested differently. dbt Labs' rule is a project-wide coverage percentage against a 100% target; this one names the individual models, which is what a worklist needs.

This means our check corresponds to their rule. It does not mean the publisher reviewed or endorses it.