Elixir untuk Technical Leader — Bab 7 dari 10

Testing & Quality

Bug yang ketemu di test = gratis. Bug yang ketemu user = mahal. LabaBersih v1 punya 0 test. v2 punya 337+.

Kenapa Test Itu Penting

Coba bayangkan ini: kamu punya function ship_order yang harus melakukan 5 hal sekaligus — ubah status, potong stok, generate jurnal penjualan, generate jurnal HPP, dan catat audit trail. Kalau salah satu gagal, semuanya harus rollback.

Di v1, kamu cuma bisa tau ini jalan dengan benar kalau Nelly coba manual di production. Bug ditemukan oleh user, bukan oleh developer.

Rule LabaBersih #5: "Setiap function WAJIB punya test." Gak ada pengecualian.

ExUnit — Framework Test Bawaan

Elixir punya framework test built-in bernama ExUnit. Gak perlu install library tambahan, gak perlu config apapun. Langsung jalan.

Jalankan semua test:

$ mix test
# Output: "337 tests, 0 failures" ← ini yang kamu mau lihat

Struktur Test — 3 Bagian

Setiap test punya 3 bagian: describe (kelompok), test (skenario), dan assert (verifikasi).

describe "ship_order/2" do
  test "ship order berhasil → status + stok + jurnal" do
    # 1. ARRANGE — siapkan data
    ctx = setup_full!()
    order = create_order!(ctx)

    # 2. ACT — jalankan function yang di-test
    {:ok, result} = Orders.ship_order(order.id, "nelly@bestari.id")

    # 3. ASSERT — verifikasi hasilnya
    assert result.order.fulfillment_status == "shipped"
    assert result.order.shipped_at != nil

    product = Inventory.get_product!(ctx.product.id)
    assert product.stok == 98
  end
end

Konvensi File Test

File test mirror file source code. Kalau kamu tau ada file lib/lababersih/orders/orders.ex, kamu otomatis tau test-nya di test/lababersih/orders/orders_test.exs.

Polanya selalu: lib/ → test/, dan nama file ditambah _test.

Setup — Data Segar Setiap Test

Setiap test butuh data untuk di-test. Di LabaBersih, setup_full!() bikin data lengkap: user, organisasi, toko, produk, stok.

defp setup_full!() do
  # Buat user + organisasi
  {:ok, %{user: user, organization: org}} =
    Accounts.register_user(%{
      email: "test-#{System.unique_integer([:positive])}@example.com",
      name: "Test User",
      password: "password123"
    })

  # Buat akun akuntansi minimal
  # Buat toko + fee mapping
  # Buat produk + stok awal 100
  # Return semua data
  %{org: org, user: user, store: store, product: product}
end

Kenapa ini penting? Karena test yang saling mengganggu = nightmare. "Test A pass sendiri tapi gagal kalau bareng test B" — itu gak pernah terjadi dengan sandbox.

Assertions — Cara Verifikasi

Assertion = klaim yang HARUS benar. Kalau salah, test gagal. Ada beberapa jenis:

assert — harus benar

# Cek status order jadi "shipped"
assert order.fulfillment_status == "shipped"

# Cek stok berkurang
assert product.stok == 98

# Cek shipped_at terisi (bukan nil)
assert order.shipped_at != nil

refute — harus salah (kebalikan assert)

# Cek order BUKAN status "dibuat"
refute order.order_status == "dibuat"

# Cek akun TIDAK aktif
refute account.is_active

Pattern matching dalam assert

# Cek return value cocok pattern {:ok, ...}
assert {:ok, result} = Orders.ship_order(order.id, "nelly@bestari.id")

# Cek error spesifik
assert {:error, :already_shipped} = Orders.ship_order(order.id, "nelly@bestari.id")

# Cek error dengan detail
assert {:error, {:insufficient_available_stock, _, _, _}} =
  Orders.create_order(big_order_attrs, items)

assert_raise — harus error (exception)

# Cek kalau order gak ada → raise error
assert_raise Ecto.NoResultsError, fn ->
  Orders.get_order!("order-yang-gak-ada")
end

Pola Testing di LabaBersih

Setiap function penting punya minimal 3 test: happy path, error path, dan edge case. Ini bukan teori — ini dari kode LabaBersih yang asli.

1. Happy Path — semuanya berjalan benar

test "ship order → atomic: status + stok + jurnal + audit" do
  ctx = setup_full!()
  order = create_order!(ctx)

  {:ok, result} = Orders.ship_order(order.id, "nelly@bestari.id")

  # Status berubah
  assert result.order.fulfillment_status == "shipped"
  assert result.order.shipped_at != nil

  # Stok berkurang (2 pcs dari 100)
  product = Inventory.get_product!(ctx.product.id)
  assert product.stok == 98

  # HPP dari FIFO lot (2 x Rp50.000 = Rp100.000)
  assert Decimal.eq?(result.hpp, Decimal.new(100_000))

  # Jurnal tercipta (penjualan + HPP)
  assert length(result.journal_ids) == 2
end

2. Error Path — input yang salah harus ditolak

test "create order stok gak cukup → rollback" do
  ctx = setup_full!()

  # Coba buat order 999 pcs (stok cuma 100)
  assert {:error, {:insufficient_available_stock, _, _, _}} =
    Orders.create_order(
      %{org_id: ctx.org.id, platform: "tiktok", store_id: ctx.store.id,
        total_harga: 5_000_000, customer_name: "Big Buyer"},
      [%{product_id: ctx.product.id, product_name: "Forbest",
         sku: "FB-001", quantity: 999, price: 5_000}]
    )

  # Stok TETAP 100 (rollback)
  product = Inventory.get_product!(ctx.product.id)
  assert product.stok == 100
  assert product.reserved_stock == 0
end

3. Edge Case — idempotent (aman dipanggil 2x)

test "ship order yang sudah dikirim → idempotent skip" do
  ctx = setup_full!()
  order = create_order!(ctx)

  # Ship pertama → berhasil
  {:ok, _} = Orders.ship_order(order.id, "nelly@bestari.id")

  # Ship kedua → skip, bukan error crash
  assert {:error, :already_shipped} = Orders.ship_order(order.id, "nelly@bestari.id")
end

4. Jurnal Balanced

test "jurnal penjualan WAJIB balanced (debit = credit)" do
  ctx = setup_full!()
  order = create_order!(ctx)
  {:ok, result} = Orders.ship_order(order.id, "nelly@bestari.id")

  # Ambil jurnal yang baru dibuat
  journals = Accounting.list_journal_entries(
    ctx.org.id, source_type: "order", source_id: order.id)

  for je <- journals do
    lines = Accounting.list_journal_entry_lines(je.id)
    total_debit = Enum.reduce(lines, Decimal.new(0), &Decimal.add(&1.debit, &2))
    total_credit = Enum.reduce(lines, Decimal.new(0), &Decimal.add(&1.credit, &2))
    assert Decimal.eq?(total_debit, total_credit)
  end
end

Ini test paling penting di akuntansi. Jurnal yang gak balance = laporan keuangan salah = keputusan bisnis salah.

Menjalankan Test

Semua test sekaligus

$ mix test

Hanya file tertentu

# Test orders saja
$ mix test test/lababersih/orders/orders_test.exs

Hanya test tertentu (by line number)

# Test yang ada di baris 122
$ mix test test/lababersih/orders/orders_test.exs:122

Hanya test yang gagal sebelumnya

$ mix test --failed

Cara Membaca Output Test

Kalau semua pass (target):

$ mix test
..................................

Finished in 4.2 seconds (0.1s async, 4.1s sync)
337 tests, 0 failures

Setiap titik (.) = 1 test yang pass. 0 failures = semua aman. Ini yang kamu mau lihat.

Kalau ada yang gagal:

$ mix test
............................F......

  1) test ship order → status + stok + jurnal (Lababersih.OrdersTest)
     test/lababersih/orders/orders_test.exs:122

     Assertion with == failed
     code:  assert product.stok == 98
     left:  100        ← NILAI YANG DIDAPAT
     right: 98         ← NILAI YANG DIHARAPKAN

Finished in 4.5 seconds
337 tests, 1 failure

Test Coverage LabaBersih v2

Ini jumlah test per context module saat ini:

Apa yang Perlu Di-test, Apa yang Tidak

WAJIB di-test:

• Business logic — ship_order, create_journal, consume_lots, process_rts
• Side effects — stok berkurang, jurnal tercipta, status berubah
• Error handling — stok gak cukup, status gak valid, jurnal gak balance
• Edge cases — idempotent, rollback, concurrent
• Validasi data — field wajib, format, constraint

GAK PERLU di-test:

• Library bawaan — jangan test apakah Enum.map jalan. Itu tanggung jawab Elixir, bukan kamu.
• UI layout — "apakah tombol warna hijau" bukan tanggung jawab test. Itu visual review.
• Database Ecto — jangan test apakah Repo.insert benar. Yang di-test: apakah changeset validasi kamu benar.

Credo — Code Quality Linter

Credo = alat yang cek kualitas kode secara otomatis. Dia gak jalankan kode, tapi baca kode dan cari yang gak rapi.

$ mix credo

Apa yang dicek Credo:

Contoh output:

$ mix credo

  Checking 84 source files ...

┃ Warnings - pleaseass these before submitting
┃
┃ [W] ↗ Modules should have a @moduledoc tag.
┃       lib/lababersih/workers/daily_sales_journal_worker.ex:1:20 #(Lababersih.Workers.DailySalesJournalWorker)

Analysis took 0.5s (0.03s to load, 0.47s running 52 checks on 84 files)
77 mods/funs, found 1 warning.

Sobelow — Security Scanner

Sobelow = alat yang cari celah keamanan di kode Phoenix.

$ mix sobelow

Apa yang dicek Sobelow:

3 Tools Quality, 3 Peran

Review Checklist untuk Leader

Setiap kali Claude bikin function baru atau update function lama, cek ini:

Red Flags — Tanda Bahaya

Kalau kamu lihat hal-hal ini, tanya Claude:

1. Function tanpa test

# Ada function baru di orders.ex
def cancel_order(order_id) do
  # ... logic ...
end

# TAPI gak ada di orders_test.exs
# ← RED FLAG! Minta Claude bikin test-nya

2. Test tanpa assertion

test "ship order" do
  ctx = setup_full!()
  order = create_order!(ctx)
  Orders.ship_order(order.id, "nelly@bestari.id")
  # ← GIT GAK ADA assert! Test ini selalu pass.
  #    Gak berguna. Minta Claude tambah assertions.
end

3. Test yang terlalu umum

test "ship order berhasil" do
  ctx = setup_full!()
  order = create_order!(ctx)
  {:ok, _} = Orders.ship_order(order.id, "nelly@bestari.id")
  # Cuma cek {:ok, _} tapi gak cek stok, gak cek jurnal, gak cek status
  # ← RED FLAG! Ship order punya 5 side effect, semua harus dicek
end

4. Skip test

@tag :skip
test "ship order" do
  # ...
end
# ← RED FLAG! Test di-skip = test gak ada.
#    Tanya: kenapa di-skip? Kapan di-enable?

Ringkasan Bab 7

Pertanyaan sederhana yang bisa kamu tanya ke Claude setiap session:

"mix test masih pass semua?"
"Function baru ini sudah ada test-nya?"
"Ada happy path, error path, dan edge case?"

Tiga pertanyaan ini saja sudah cukup untuk menjaga kualitas kode LabaBersih.