dbt Tests: Mencegah Angka Salah Sampai ke Dashboard

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.

Kenapa perlu test kalau query-nya udah dicek manual?

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.

Apa itu 4 test bawaan dbt?

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.

Gimana cara nulis test bawaan?

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_produk

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

Gimana cara jalanin test?

Dari folder proyek:

dbt test

Kalau 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=8

Angka 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_transaksi

Gimana cara bikin test custom pakai SQL?

Kalau 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 < 0

Contoh 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 * 5

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

Gimana cara bikin test yang bisa dipakai ulang?

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: 500

Gimana cara atur test yang gagal tapi bukan darurat?

Nggak semua masalah harus nyetop pipeline. Atur pakai severity:

      - name: kode_pelanggan
        tests:
          - not_null:
              config:
                severity: warn

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

Kapan pakai dbt build, bukan dbt run?

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 build

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

Contoh kasus: 6 bulan test jalan di data toko_berkah

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.

Kesalahan umum waktu pakai dbt tests

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.

FAQ

dbt test itu ngecek datanya atau kodenya?

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.

Bedanya dbt test sama dbt build apa?

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.

Berapa banyak test yang wajar per model?

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.

Kalau test gagal tapi datanya emang begitu, gimana?

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.

Test harus dijalanin kapan?

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.

Penutup

Yang bisa kamu kerjain hari ini:

• Pasang unique dan not_null di kolom ID model staging kamu. Dua baris yaml, dan itu udah nutup masalah paling mahal.
• Ganti perintah harian kamu dari dbt run jadi dbt build.
• Tulis satu test custom buat pola aneh yang pernah beneran kejadian di data kamu.

Kalau kamu belum punya proyek dbt sama sekali, mulai dari model dbt pertama pakai data toko berkah, lalu balik ke sini buat pasang penjaganya.