Belajar Jest - Security & Test Reliability

#Pendahuluan

Test suite yang baik tidak hanya menguji kode — dia juga harus aman dan andal. Episode 13 membahas dua sisi yang sering terabaikan: security dan test reliability. Di sisi keamanan, kalian harus mencegah test membocorkan data sensitif seperti API key atau token. Di sisi keandalan, suite harus deterministik dan repeatable — hasil yang sama di mesin mana pun.

Kedua topik ini menentukan apakah kalian berani mempercayai suite sebagai pengaman rilis. Suite yang bocor data atau sering gagal acak akan diabaikan tim, dan kehilangan fungsinya sama sekali.

#Mencegah Test Membocorkan Data Sensitif

#Jangan Menulis Secret di Kode Test

Aturan pertama: secret seperti API key, token, dan password tidak boleh muncul di kode test atau snapshot. Snapshot yang menampilkan respons API sering secara tidak sengaja menyimpan token — dan snapshot itu kemudian di-commit ke Git selamanya.

Membaca secret dari environment, bukan hardcode

test("client memakai token dari env", () => {
  const token = process.env.API_TOKEN;
  expect(token).toBeDefined();
  expect(token).not.toBe("sk-live-xxxxxxxxxxxx");
});

process.env.API_TOKEN memaksa secret dibaca dari environment, bukan ditulis langsung di test. Assertion not.toBe("sk-live-...") adalah jaring pengaman tambahan agar placeholder yang mirip secret nyata tidak lolos.

#Sanitasi Log dan Snapshot

Jika kode yang diuji mencetak data sensitif, pastikan logging dimatikan atau disanitasi saat test. Mock logger agar tidak menulis ke konsol, dan periksa isi snapshot sebelum commit. Konsol yang penuh token saat test berjalan adalah tanda bahaya yang harus segera diperbaiki.

#Mengisolasi Logika Spesifik Environment

#Membedakan Mode Test dan Produksi

Kode yang berperilaku berbeda per environment harus diuji untuk setiap mode secara eksplisit. Jangan membiarkan behavior test bocor ke produksi atau sebaliknya:

Menguji perilaku per environment

function urlAPI() {
  if (process.env.NODE_ENV === "production") {
    return "https://api.example.com";
  }
  return "http://localhost:8080";
}
 
test("URL berbeda untuk production", () => {
  const lama = process.env.NODE_ENV;
  process.env.NODE_ENV = "production";
  expect(urlAPI()).toBe("https://api.example.com");
  process.env.NODE_ENV = lama;
});

Kode yang mengubah process.env di dalam test harus mengembalikannya ke nilai semula — baris process.env.NODE_ENV = lama menjamin hal itu, agar test lain tidak terpengaruh.

#Menjaga Konfigurasi Terpusat

Sebisa mungkin, isolasi logika environment di satu modul konfigurasi yang diuji sekali, alih-alih menyebarkan if (process.env...) di banyak file. Ini mengurangi risiko test yang bergantung pada state global yang tidak terkendali.

#Membuat Test Deterministik dan Repeatable

#Menghindari Dependensi Waktu dan Acak

Test yang mengandalkan waktu saat ini atau angka acak sulit diulang hasilnya. Gunakan fake timers untuk waktu, dan inject nilai acak lewat parameter:

Menguji kode bergantung waktu

jest.useFakeTimers();
jest.setSystemTime(new Date("2026-08-10T00:00:00Z"));
 
function kunciHari() {
  return new Date().toISOString().slice(0, 10);
}
 
test("kunci hari stabil", () => {
  expect(kunciHari()).toBe("2026-08-10");
});

jest.setSystemTime(new Date("2026-08-10T00:00:00Z")) mengunci tanggal, sehingga test menghasilkan nilai yang sama kapan pun dijalankan — di laptop maupun di CI.

#Menghindari Urutan Eksekusi Tersembunyi

Jangan pernah menulis test yang hasilnya bergantung pada urutan file test dijalankan. Setiap test harus membangun state-nya sendiri di beforeEach dan membuangnya di afterEach. Ini adalah kunci determinisme di suite yang berjalan paralel.

#Menghindari Flaky Tests

#Setup dan Teardown yang Benar

Flaky test hampir selalu berasal dari setup yang tidak lengkap: file yang tidak dibersihkan, timer yang belum habis, atau mock yang tidak di-reset. Pola standar yang menyeluruh:

Pola setup teardown anti flaky

beforeEach(() => {
  jest.clearAllMocks();
});
 
afterEach(() => {
  jest.useRealTimers();
  nock.cleanAll();
});

jest.useRealTimers() mengembalikan timer nyata setelah setiap test — mencegah fake timers bocor ke test berikutnya. Kombinasi clearAllMocks dan cleanAll menjaga mock dan interceptor bersih.

#Investigasi yang Disiplin

Saat test flaky muncul, jangan abaikan. Catat polanya, reproduksi dengan --runInBand, dan perbaiki akar masalahnya. Test yang flaky yang dibiarkan akan menumpuk dan akhirnya menggerus kepercayaan tim terhadap seluruh suite.

#Penutup

Episode 13 membahas keamanan dan keandalan suite: menjauhkan secret dari kode test dan snapshot, mengisolasi logika per environment, membangun test yang deterministik dan repeatable, serta menghindari flaky tests dengan setup dan teardown yang disiplin.

Inti yang harus dibawa pulang:

• Secret tidak boleh ada di kode test atau snapshot — baca dari environment.
• Uji perilaku per environment secara eksplisit dan kembalikan env setelahnya.
• Fake timers membuat test bergantung waktu menjadi deterministik.
• Setiap test membangun state sendiri; jangan bergantung pada urutan.
• Bersihkan mock, timer, dan interceptor di afterEach.
• Investigasi flaky test sampai tuntas; jangan biarkan menumpuk.

Di episode 14 selanjutnya kita akan membahas running Jest in CI/CD — integrasi ke GitHub Actions, GitLab CI, dan Jenkins, eksekusi paralel dan test splitting, fail fast dengan selective test runs, serta pelaporan hasil dan coverage badges.