---
title: "dbt models with no tests | Metacenta"
description: "Why a dbt model with no tests fails silently, the two tests every model should start with, and when a model can reasonably go without."
url: "https://metacenta.com/rules/model-untested"
updated: "2026-10-14"
tokens: 712
---

Testing · rule model-untested

# dbt models with no tests

A Metacenta review checks this under the rule **Models have at least one test**. Everything below applies whether or not you ever commission one.

## What this rule checks

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.

## Why it matters

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.

## How to fix it

**Give every model at least one test.** 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:

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

After:

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

## When it is fine to leave

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.

## What we need to check it

`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.

## Published rules it corresponds to

**[dbt_project_evaluator](https://dbt-labs.github.io/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.

[Ask about a review](https://metacenta.com/enquire?src=rule-model-untested&via=md)

## Related pages

- [dbt unique_combination_of_columns: how to use it](https://metacenta.com/rules/model-grain-not-asserted)
- [dbt key columns: no not_null test](https://metacenta.com/rules/model-no-not-null-test)
- [SQL tables with no assertion](https://metacenta.com/rules/sql-relation-untested)
- [Dagster asset checks: how to set them up](https://metacenta.com/rules/dagster-asset-unchecked)
- [This rule in a sample review](https://metacenta.com/sample#constructed)
- [All published rules](https://metacenta.com/rules)
- [How a review is assessed](https://metacenta.com/standard)