TL;DR
dbt tests adalah pemeriksaan otomatis yang jalan setelah model dibangun, buat mastiin datanya masuk akal sebelum dipakai dashboard. Empat test bawaan yang paling kepakai: unique, not_null, accepted_values, dan relationships. Tulis di file yaml sebelah model, lalu jalankan dbt test atau dbt build biar test langsung ikut tiap kali model dibangun.
dbt tests adalah pemeriksaan otomatis yang jalan setelah model dibangun, buat mastiin datanya masuk akal sebelum dipakai dashboard.
Bentuknya query SQL yang nyari baris bermasalah. Nol baris berarti aman, satu baris berarti ada yang perlu dicek.
Di tutorial ini kamu bakal pasang 4 test bawaan, bikin 2 test custom, atur tingkat keparahannya, lalu ngerti kapan pakai dbt build.
Karena yang berubah bukan query kamu, tapi datanya.
Query yang benar hari ini bisa ngasilin angka salah bulan depan gara-gara sistem kasir nambah kolom, ada cabang baru yang nama kotanya beda format, atau satu hari datanya kekirim dua kali.
Di data toko_berkah yang aku pakai buat latihan, dalam 6 bulan ada tiga kejadian kayak gini. Yang paling parah: satu batch transaksi ke-load dua kali, dan omzet 14 Agustus jadi Rp47.200.000 padahal seharusnya Rp23.600.000. Persis dua kali lipat.
Nggak ada yang sadar selama 9 hari. Test unique di kolom id_transaksi bakal nangkep itu dalam hitungan detik.
dbt punya empat test generik yang langsung bisa dipakai tanpa nulis SQL sama sekali:
| Test | Ngecek apa | Contoh masalah yang ketangkep |
|---|---|---|
| unique | Nggak ada nilai kembar di kolom | Data ke-load dua kali |
| not_null | Nggak ada sel kosong | Kolom tanggal bolong |
| accepted_values | Isi kolom cuma dari daftar tertentu | Muncul status baru yang belum ditangani |
| relationships | Nilai kolom ada di tabel lain | ID produk yang nggak ada di master produk |
Empat ini nutup sebagian besar masalah harian. Sisanya baru butuh test custom.
Test ditulis di file yaml yang ditaruh sebelah model. Bikin file models/staging/stg_transaksi.yml:
version: 2
models:
- name: stg_transaksi
description: Transaksi kasir yang sudah dibersihkan
columns:
- name: id_transaksi
description: ID unik per baris transaksi
tests:
- unique
- not_null
- name: tanggal
tests:
- not_null
- name: nama_cabang
tests:
- not_null
- accepted_values:
values:
- SOLO PUSAT
- SEMARANG BARAT
- KLATEN
- SALATIGA
- name: id_produk
tests:
- not_null
- relationships:
to: ref('stg_produk')
field: id_produkKalau kamu belum punya model stg_transaksi, mulai dulu dari tutorial bikin model dbt pertama.
Perhatiin test relationships. Dia ngecek setiap id_produk di tabel transaksi punya pasangan di tabel produk. Waktu aku jalanin ini pertama kali, ketahuan 47 transaksi nunjuk ke produk yang udah dihapus dari master. Semua laporan per kategori jadi kurang Rp3.140.000 gara-gara baris itu nggak kejoin.
Dari folder proyek:
dbt testKalau ada yang gagal, keluarnya gini:
Failure in test unique_stg_transaksi_id_transaksi
Got 118 results, configured to fail if != 0
compiled Code at target/compiled/.../unique_stg_transaksi_id_transaksi.sql
Done. PASS=7 WARN=0 ERROR=1 SKIP=0 TOTAL=8Angka 118 itu jumlah nilai id_transaksi yang muncul lebih dari sekali.
Mau lihat baris mananya? Buka file SQL yang disebut di baris compiled Code, terus jalanin query-nya langsung di database. Atau pakai flag store_failures biar hasil gagalnya disimpan jadi tabel.
Buat test satu model aja:
dbt test --select stg_transaksiKalau yang mau kamu cek nggak masuk empat test bawaan, tulis query sendiri. Aturannya cuma satu: query itu harus balikin baris yang bermasalah. Nol baris berarti lolos.
Taruh file SQL-nya di folder tests/. Contoh, tests/nilai_transaksi_tidak_negatif.sql:
select
id_transaksi,
total_rupiah
from {{ ref('stg_transaksi') }}
where total_rupiah < 0Contoh kedua yang lebih berguna, ngecek lonjakan omzet harian yang nggak wajar. Simpan sebagai tests/omzet_harian_wajar.sql:
with harian as (
select
tanggal,
sum(total_rupiah) as omzet
from {{ ref('stg_transaksi') }}
group by tanggal
),
patokan as (
select percentile_cont(0.5) within group (order by omzet) as median_omzet
from harian
)
select h.tanggal, h.omzet
from harian h
cross join patokan p
where h.omzet > p.median_omzet * 5Test ini yang bakal nangkep kasus data ke-load dua kali walaupun ID-nya kebetulan beda. Aku pakai median, bukan rata-rata, soalnya rata-rata gampang ketarik sama hari Ramadan. Alasan yang sama kayak kenapa MEDIAN di spreadsheet lebih aman buat data yang miring.
Kalau test yang sama mau dipakai di banyak kolom, bikin generic test. Taruh di folder macros/, misalnya macros/test_dalam_rentang.sql:
{% test dalam_rentang(model, column_name, batas_bawah, batas_atas) %}
select *
from {{ model }}
where {{ column_name }} < {{ batas_bawah }}
or {{ column_name }} > {{ batas_atas }}
{% endtest %}Pakainya di yaml:
- name: qty
tests:
- dalam_rentang:
batas_bawah: 1
batas_atas: 500Nggak semua masalah harus nyetop pipeline. Atur pakai severity:
- name: kode_pelanggan
tests:
- not_null:
config:
severity: warnDengan warn, test tetap dilaporkan tapi pipeline jalan terus.
Yang lebih berguna lagi, ambang batas bertingkat:
- name: kode_pelanggan
tests:
- not_null:
config:
severity: error
warn_if: "> 10"
error_if: "> 100"Artinya: di bawah 10 baris kosong dianggap normal, 11 sampai 100 kasih peringatan, di atas 100 baru bikin gagal.
Setelan ini yang bikin test kepakai jangka panjang. Test yang bunyi tiap hari bakal diabaikan tim dalam dua minggu.
dbt build ngerjain bangun model dan test-nya secara berurutan per model. Kalau test di model A gagal, model B yang bergantung ke A nggak ikut dibangun.
dbt buildIni yang bikin dia beda dari jalanin dbt run lalu dbt test. Dengan urutan itu, semua model terlanjur dibangun sebelum test-nya jalan, jadi angka salah udah nyampe tabel akhir.
Buat jadwal harian, pakai dbt build. Selalu.
Rincian perilakunya bisa dicek di dokumentasi resmi dbt soal perintah build.
Aku pasang 24 test di 7 model, lalu jalanin dbt build tiap pagi selama 6 bulan. Ini yang ketangkep:
| Jenis masalah | Ketangkep oleh | Jumlah kejadian |
|---|---|---|
| Data ke-load dua kali | unique | 2 |
| Kolom tanggal kosong | not_null | 9 |
| Cabang baru belum terdaftar | accepted_values | 3 |
| ID produk yatim | relationships | 4 |
| Lonjakan omzet tidak wajar | test custom | 1 |
Total 19 kejadian dalam 6 bulan, atau sekitar satu masalah tiap 9 hari.
Angka yang paling bikin aku berhenti sebentar: sebelum ada test, rata-rata masalah kayak gini baru ketahuan 11 hari setelah kejadian, biasanya waktu ada orang yang nanya kenapa grafiknya aneh. Setelah test jalan, ketahuannya dalam 1 hari.
Selisih 10 hari itu artinya 10 hari keputusan diambil dari angka yang benar.
Test kayak gini yang bikin standar kualitas data beneran jalan, bukan cuma tertulis di dokumen. Aturan mainnya sendiri aku bahas di data governance untuk tim data kecil.
1. Cuma pasang test di model akhir. Masalah paling gampang diperbaiki di lapisan staging. Kalau baru ketahuan di model marts, kamu harus telusuri balik.
2. Bikin 40 test di satu model. Waktu jalannya lama dan tim mulai ngeskip. Tiga sampai enam test per model udah cukup.
3. Set semua test severity error. Kalau pipeline berhenti gara-gara 2 baris kode pelanggan kosong, orang bakal matiin test-nya. Pakai ambang batas.
4. Jalanin dbt run lalu dbt test terpisah. Angka salah terlanjur nyampe tabel akhir. Pakai dbt build.
5. Nggak nyimpen baris yang gagal. Aktifkan store_failures biar kamu bisa lihat baris masalahnya tanpa nulis query manual.
6. Nulis accepted_values lalu lupa diperbarui. Waktu cabang ke-13 buka, test-nya bakal gagal. Itu justru gunanya, tapi pastiin ada yang tanggung jawab memperbarui daftarnya.
7. Nggak test tabel sumber. Test bisa dipasang di source juga, dan itu yang paling awal nangkep masalah. Tambahin blok tests di file source kamu.
Datanya. dbt test jalanin query yang nyari baris bermasalah di tabel hasil. Kalau query itu balikin nol baris, test lolos. Kalau balikin satu baris atau lebih, test gagal dan barisnya bisa kamu lihat. Jadi test ini nggak ngecek SQL kamu benar secara sintaks, tapi ngecek hasil akhirnya masuk akal atau nggak.
dbt run cuma bangun model. dbt test cuma jalanin test. dbt build ngerjain dua-duanya secara berurutan per model: bangun model, langsung test, baru lanjut ke model berikutnya yang bergantung padanya. Kalau test gagal, model turunannya nggak ikut dibangun. Buat jadwal harian, dbt build yang paling aman.
Patokan praktisnya 3 sampai 6 test per model. Minimal satu unique dan satu not_null di kolom kunci. Lebih dari 10 test per model biasanya tanda modelnya kebanyakan tanggung jawab dan sebaiknya dipecah. Yang penting bukan jumlahnya, tapi apakah test itu bakal nangkap masalah yang beneran pernah terjadi.
Turunin tingkat keparahannya jadi warn, atau kasih ambang batas lewat error_if dan warn_if. Misalnya, kamu tau ada 12 baris tanpa kode pelanggan dan itu wajar. Set error_if lebih dari 20 baris, biar test cuma bunyi kalau masalahnya membesar. Jangan hapus test-nya, soalnya kamu kehilangan penjaga.
Setiap kali pipeline harian jalan, dan setiap kali kamu ubah model sebelum kode masuk ke cabang utama. Dua momen itu yang nutup sebagian besar risiko. Kalau kamu pakai penjadwal, taruh dbt build sebagai satu langkah dan bikin dia gagal keras kalau ada test error, biar dashboard nggak keburu kebaca angka salah.
Yang bisa kamu kerjain hari ini:
unique dan not_null di kolom ID model staging kamu. Dua baris yaml, dan itu udah nutup masalah paling mahal.dbt run jadi dbt build.Kalau kamu belum punya proyek dbt sama sekali, mulai dari model dbt pertama pakai data toko berkah, lalu balik ke sini buat pasang penjaganya.
Mau praktek langsung? Mulai latihan SQL gratis
Latihan interaktif, langsung di browser.
Kolom datetime nyimpen tanggal, jam, hari, semuanya nempel jadi satu. Accessor .dt di pandas ngeluarin tiap bagian jadi kolom sendiri buat dianalisa.
Nama toko ketik campur huruf besar-kecil, spasi nyasar di ujung, atau kode produk nempel jadi satu. Accessor .str di pandas ngerapiin semua itu tanpa loop.
Model machine learning cuma ngerti angka, bukan teks kayak merah atau biru. get_dummies ngubah kolom kategori jadi kolom 0/1 dalam satu baris kode.