在 DAY 08 我們示範了最基本的 Generic tests。
DAY 16 也提到了除了內建的 Generic Tests 外，也可以額外安裝 Packages，使用 dbt_utils 裡面的 Generic Tests。

今天要來談的是更進一步的 Singular Test，如果 Generic Tests 不適用的話，可以直接自行定義 Tests。

Singular Test

回到 DAY 08 我們曾針對 stg_orders 的 status 欄位作檢核。該欄位允許的值為 ['placed', 'shipped', 'completed', 'return_pending', 'returned']，如果出現了其他的值，則 Test 失敗。

讓我們來試試看把該 Test 寫成 Singular Test。

Singular Test 就是自己定義一段 SQL 語法，篩選出 test 失敗的列數。
如果篩選出來沒有資料，就代表 test 通過。
（Generic Test 其實也是一樣的原理，只是不用自己下 SQL）

如何定義 Singular Test

首先，在根目錄的 test 資料夾底下，新增檔案 test_order_statuses_accepted_values.sql，貼入以下內容。

select *
from {{ ref('stg_orders' ) }}
where
    status not in (
        'placed', 'shipped', 'completed', 'return_pending', 'returned'
    )

試跑一次 Test 結果為成功。

同樣的，我們製造一個 test 失敗的情境，拿掉一些狀態，將 test 定義改為以下內容：

select *
from {{ ref('stg_orders' ) }}
where
    status not in ('placed', 'shipped', 'completed')

再跑一次 Test，結果為不通過。

儲存 test 失敗的資料

不管是 Generic Tests 或是 Singular Tests，都有可能發生 Test 失敗的狀況。
這時候我們就需要去檢查資料、看是哪裡出錯。

現在要介紹的是，如何把 test 失敗的資料保留起來，方便檢查。

如何儲存及查看 test 失敗的資料

只要在跑 test 的指令加上 --store-failures 就會自動儲存 test 失敗的資料。

dbt test --store-failures

如果不想下在指令的話，也可以在 config 定義。
例如在 dbt_project.yml 加入以下這一段，就會預設所有的 tests 都要儲存失敗資料。

tests:
  +store_failures: true

預設儲存位置是

• Schema/dataset: 預設的schema/dataset名稱 + _dbt_test__audit 後綴。
• table name: Test 名稱

例如我在開發環境的預設 dataset 是 dbt_dev，test 名稱是 test_order_statuses_accepted_values，那麼沒通過 test 的資料就會被存在 dbt_dev_dbt_testaudit.test_order_statuses_accepted_values

檢查 test 失敗的資料

select * from dbt_dev_dbt_test__audit.test_order_statuses_accepted_values

可以看到 test 失敗的就是被我們故意拿掉的 statuses: returned, return_pending。

今日小結＆明日預告

接續 DAY 08，我們今天更進一步介紹了 Singular Test，如果不想用 Generic Tests，就可以使用自由定義的 Singular Tests。

以及 Test 失敗的下一步，我們可以將 Test 失敗的資料儲存起來，方便之後查看及除錯。

明天的主題：Incremental Materializations，只更新部份資料，提昇速度，節省運算資源。

參考資料

• Add tests to your DAG https://docs.getdbt.com/docs/build/tests

歡迎加入 dbt community
對 dbt 或 data 有興趣 👋？歡迎加入 dbt community 到 #local-taipei 找我們，也有實體 Meetup 請到 dbt Taipei Meetup 報名參加