Unit Test JavaScript: Panduan Komprehensif 2026

Kamu mungkin berada di salah satu situasi di bawah ini. Entah proyek JavaScript kamu hampir tidak memiliki tes dan setiap refactor terasa berisiko, atau kamu sudah memiliki tes dan separuh di antaranya lambat, rapuh, dan sulit dipercaya.

itu semakin buruk di Capacitor dan Aplikasi Electron. Suatu fitur sederhana dapat menyentuh logika bisnis bersama, API browser, plugin native, file lokal, IPC, dan layanan jarak jauh dalam aliran yang sama. Jika kamu menguji bagian-bagian tersebut dengan cara yang salah, suite tes kamu akan menjadi labirin dependensi palsu. Jika kamu mengujinya dengan cara yang benar, kamu akan mendapatkan feedback cepat pada logika yang rusak. Pengujian unit JavaScript yang baik tidak dimulai dengan sintaks matcher yang cerdas. Ini dimulai dengan batasan disiplin: uji logika murni secara langsung, isolasi efek sampingan, dan hindari menulis tes yang runtuh ketika kamu mengubah nama fungsi internal.

Tabel Konten

Pilih Framework Pengujian JavaScript

• Mengapa framework bukanlah optional
  • Mengapa framework bukanlah optional
  • Jest vs Mocha dari Perspektif Ringkas
  • Apa yang Saya Sarankan untuk Tim yang Banyak
• Pengaturan Proyek dan Ujian Pertama Anda
  • Pengaturan Jest yang Sederhana
  • Tulis Ujian Sebelum Membuat code
  • Pakai Arrange Act Assert Setiap Kali
• Menguasai Mock dan Code Asinkron
  • Simulasikan Batasan, Bukan Semua
  • Polanya Lebih Baik untuk Capacitor dan Electron code
  • Menguji Aliran Asinkron Tanpa Gangguan
• Saat Strategi Lanjutan untuk Ujian yang Kuat
  • Pakai Pembagian Ujian sebagai Anggaran
  • Coverage adalah sebuah lampu sorot, bukan target
  • Uji coba berdasarkan perilaku dapat bertahan dari refactor
• Pengujian untuk CI, Capacitor, dan Aplikasi Electron
  • Ubah CI menjadi jalur eksekusi default
  • Pengujian interaksi plugin Capacitor
  • Pengujian Electron main renderer dan IPC code
• Frequently Asked Questions Tentang Pengujian Satuan JavaScript
  • Apa perbedaan antara pengujian unit, integrasi, dan E2E
  • Apakah kita harus mencapai coverage penuh
  • Bagaimana cara menambahkan uji coba ke kodebase yang sudah ada

Pemilihan Framework Pengujian JavaScript

Proyek JavaScript profesional membutuhkan runner pengujian yang nyata. Skrip ad hoc dan pengecekan console manual tidak dapat berkembang ketika beberapa insinyur menyentuh kodebase yang sama. Anda membutuhkan penemuan uji coba, asertasi, penanganan async, mock, dan cara menjalankan semuanya secara konsisten dalam pengembangan lokal dan CI.

Guidan berlapis saat ini selalu berkonvergensi pada sekelompok pilihan utama. Jest, Mocha, dan Jasmine seringkali dihimbau sebagai kerangka utama, dengan Jest seringkali dihimbau karena struktur tes bawaan, asertasi, pemalsuan, dan dukungan async dalam satu paket, seperti yang ditunjukkan dalam laboratorium tes JavaScript Pluralsight ini Tabel perbandingan yang menampilkan kerangka tes JavaScript populer termasuk Jest, Mocha, Cypress, dan Playwright.

Kesalahan pertama tim membuat adalah menganggap tes unit sebagai kegiatan sampingan. Biasanya hal ini menyebabkan penamaan file tidak konsisten, asertasi kustom yang tidak diingat, dan bantuan yang hanya dipahami oleh satu orang

Kerangka memberikan Anda bahasa bersama:

Struktur tes

• dengan dengan describe atau test atau it
• Assertions dengan matchers yang dapat dibaca
• Hooks untuk pengaturan dan penghapusan
• Support Asinkron untuk janji dan timer
• Alat Mocking untuk dependensi luar

Jika tim Anda juga memerlukan pandangan yang lebih luas tentang otomatisasi tes di luar pekerjaan tingkat unit, Capgo memiliki gambaran umum yang berguna tentang pengujian otomatis dalam alur pengiriman aplikasi.

Jest vs Mocha secara singkat

Jest dan Mocha mewakili dua filosofi yang berbeda.

Jest adalah pilihan semua dalam satu. Ini membawa kebanyakan dari apa yang dibutuhkan tim pada hari pertama.
Mocha lebih modular. Ini memberikan Anda runner dan mengharapkan Anda untuk menyusun sisa dari stack.

Aturan praktis: Jika tim Anda harus bertanya tentang perpustakaan asertasi dan perpustakaan mocking mana yang harus dipasangkan dengan runner, kemungkinan besar Anda ingin menggunakan Jest.

Rekomendasi saya untuk tim kebanyakan

Untuk proyek modern kebanyakan, saya akan memilih Jest kecuali basis kode sudah memiliki alasan kuat untuk tetap menggunakan Mocha. Rekomendasi ini semakin kuat ketika aplikasi termasuk Capacitor atau ElectronKarena proyek-proyek tersebut sudah memiliki bagian yang cukup bergerak. Mengurangi penyebaran alat pengujian membayar kembali dengan cepat.

Mocha masih memiliki arti dalam layanan Node.js yang lebih tua atau kodebasis yang lebih lama, di mana ekosistem di sekitarnya sudah terjalin dengan baik. Namun, bagi seorang insinyur menengah yang mengatur suatu suite yang kuat dari awal, Jest biasanya menghilangkan lebih banyak gesekan daripada yang dibuat.

Catatan penting tentang ruang lingkup. Cypress dan Playwright adalah alat-alat yang sangat baik, tetapi mereka menyelesaikan masalah yang berbeda. Mereka lebih baik untuk pengujian browser-level dan end-to-end, bukan loop dalam yang cepat di mana unit test JavaScript seharusnya hidup.

Pengaturan Proyek dan Ujian Pertama

Suatu pengaturan pengujian yang bersih seharusnya membosankan. Jika menambahkan ujian pertama terasa rumit, maka suite mungkin tidak akan tetap sehat.

Pengaturan Jest yang Sederhana

Mulai dengan proyek JavaScript yang sudah memiliki package.jsonkemudian tambahkan Jest sebagai dependensi pengembangan dan hubungkan skrip pengujian.

{
  "scripts": {
    "test": "jest"
  }
}

itu sudah cukup untuk banyak proyek. Anda dapat menambahkan konfigurasi lebih lanjut jika sistem modul, transpilasi, atau struktur monorepo memerlukan.

Jika Anda sedang membangun aplikasi Capacitor secara lokal dan ingin lingkungan pengembangan Anda dalam kondisi sebelum menambahkan ujian di sekitar logika yang dibagikan, Capgo's guide ke pengaturan lingkungan lokal Capacitor adalah teman sehari-hari yang praktis.

Tulislah tes sebelum code

Polanya tes pertama bukan hanya preferensi pribadi. Badan Perlindungan Konsumen Keuangan Amerika Serikat secara eksplisit merekomendasikan menulis tes terlebih dahulu, mengorganisir tes dengan describe dan it, dan mengatur periksa sekitar expect(...) asertasi dalam panduan tes unit JavaScriptnya Hal itu penting karena perubahan tes pertama mengubah cara Anda merancang __CAPGO_KEEP_0__. Fungsi cenderung menjadi lebih kecil, ketergantungan menjadi lebih terlihat, dan efek sampingan berhenti bocor ke logika yang harus tetap murni..

That matters because test-first changes how you design code. Functions tend to become smaller, dependencies become more visible, and side effects stop leaking into logic that should stay pure.

Gunakan Siapkan Lakukan Periksa setiap kali

// math.js
function addTax(amount, rate) {
  return amount + amount * rate;
}

module.exports = { addTax };

// math.test.js
const { addTax } = require('./math');

describe('addTax', () => {
  it('returns the amount with the tax applied', () => {
    expect(addTax(100, 0.2)).toBe(120);
  });
});

Gunakan Siapkan Lakukan Periksa setiap kali

The Mengatur, Melakukan, Mengasertasi polanya menjaga tes tetap dapat dibaca, bahkan ketika mereka tumbuh lebih kompleks.

1. Mengatur masukkan input dan setup yang diperlukan.
2. Melakukan dengan memanggil fungsi.
3. Mengasertasi pada hasilnya.

Diterapkan pada helper validasi:

function isSupportedPlatform(platform) {
  return ['ios', 'android', 'web', 'desktop'].includes(platform);
}

describe('isSupportedPlatform', () => {
  it('returns true for ios', () => {
    // Arrange
    const platform = 'ios';

    // Act
    const result = isSupportedPlatform(platform);

    // Assert
    expect(result).toBe(true);
  });
});

Tes kecil bertahan lama. Sebuah tes biasanya harus menjawab satu pertanyaan, bukan menceritakan alur kerja yang lengkap.

Untuk Capacitor dan Electron project, disiplin itu lebih penting karena logika murni Anda sering kali berada di samping integrasi native atau desktop code. Jaga aturan bisnis tetap dapat diuji tanpa runtime platform, dan tes pertama Anda tidak akan menjadi tes terakhir yang berguna.

Menguasai Mocks dan Asinkron Code

Banyak bug di aplikasi code tidak berasal dari menambahkan dua angka. Mereka berasal dari code yang mencapai luar diri: permintaan jaringan, file, API plugin, timer, saluran IPC, lapisan penyimpanan.

Itu di mana mocking membantu. Ini memberikan Anda kontrol atas batasan sehingga tes dapat fokus pada keputusan code.

Mock batasan, bukan semuanya

Pedoman tes yang dapat dipertahankan menekankan penutupan perilaku tunggal dan asertasi kuat satu per tes, dan juga mengingatkan bahwa menggunakan mock yang berlebihan membuat tes menjadi rapuh dan terikat pada detail implementasi, seperti yang disinggung dalam artikel TestRail tentang tes unit yang dapat dipertahankan.

Pesan itu sangat penting di JavaScript. Tim sering mulai dengan mengmock semua modul yang diimport dan akhirnya menguji apakah fungsi memanggil fungsi lain dalam urutan yang

Target yang buruk untuk tes mock-heavy:

• apakah helper A memanggil helper B
• apakah layanan C memanggil serializer D
• apakah fungsi internal privat berjalan dua kali

Target yang lebih baik:

• apa yang dikembalikan oleh fungsi
• apakah fungsi tersebut menangani ketergantungan yang gagal dengan benar
• apakah fungsi tersebut mengubah data menjadi bentuk yang diharapkan

Polanya yang lebih baik untuk Capacitor dan Electron code

Dalam aplikasi mobile dan desktop, saya lebih suka layer penutup di sekitar API native atau platform. Kemudian, tes unit memalsukan layer penutup, bukan platform itu sendiri.

Struktur contoh:

// cameraGateway.js
async function getPhoto(cameraPlugin) {
  return cameraPlugin.getPhoto();
}

module.exports = { getPhoto };

// profilePhotoService.js
async function loadProfilePhoto(cameraGateway) {
  const photo = await cameraGateway.getPhoto();
  return { path: photo.path, ready: true };
}

module.exports = { loadProfilePhoto };

// profilePhotoService.test.js
const { loadProfilePhoto } = require('./profilePhotoService');

test('returns mapped photo data', async () => {
  const fakeCameraGateway = {
    getPhoto: jest.fn().mockResolvedValue({ path: '/tmp/pic.jpg' })
  };

  const result = await loadProfilePhoto(fakeCameraGateway);

  expect(result).toEqual({ path: '/tmp/pic.jpg', ready: true });
});

Polanya itu juga berlaku untuk Electron. Tutup layer di sekitar platform ipcRendererfile akses, atau integrasi shell di balik adapter tipis.

Untuk tim yang menguji logika rilis dan jalur pembaruan di aplikasi Capacitor, Capgo memiliki panduan relevan tentang menguji pembaruan OTA Capacitor dengan skenario mock.

Petunjuk singkat membantu jika tim Anda masih mengnormalisasi gaya tes async:

Menguji aliran async tanpa fluktuasi

Pakai async/await dalam tes ketika code yang diuji kembali janji. Lebih jelas daripada pola callback berat dan lebih mudah untuk di-debug.

async function fetchProfile(api) {
  const response = await api.getUser();
  return response.name;
}

test('returns the user name from the API response', async () => {
  const api = {
    getUser: jest.fn().mockResolvedValue({ name: 'Ava' })
  };

  const result = await fetchProfile(api);

  expect(result).toBe('Ava');
});

Juga uji jalur gagal:

test('throws when the API request fails', async () => {
  const api = {
    getUser: jest.fn().mockRejectedValue(new Error('network failed'))
  };

  await expect(fetchProfile(api)).rejects.toThrow('network failed');
});

Uji baik jalur bahagia dan jalur jelek. Di produksi, jalur jelek biasanya adalah satu yang pengguna ingat.

Strategi Lanjutan untuk Tes yang Kuat

Sebuah suite tes menjadi berguna ketika tetap berguna setelah code berubah. Itu lebih sulit daripada menulis tumpukan tes yang berhasil.

Gunakan pembagian tes sebagai anggaran

Satu panduan praktek merekomendasikan pembagian 70/20/10 pembagian acrossunit, integrasi, dan tes akhir-ke-akhir , dengan tes unit memberikan feedback yang paling cepat dan gagal yang paling stabil.Guidance yang sama mengatakan bahwa suatu suite unit penuh seharusnya selesai dalam kurang dari 10 detik, dan periksa pre-commit harus tetap kurang dari 5 detik.

, menurut panduan tes OpenReplay

Saya menganggap itu sebagai alat anggaran, bukan agama. Jika sebagian besar upaya Anda masuk ke tes akhir-ke-akhir, tim Anda akan menunggu terlalu lama untuk mendapatkan feedback. Jika semuanya adalah unit-saja, Anda akan melewatkan batasan sistem yang nyata. Untuk aplikasi Capacitor atau Electron, keseimbangan yang sehat biasanya terlihat seperti ini:

• Unit test untuk logika harga, aturan akses, serialisasi, kelayakan pembaruan, flag fitur, dan transformasi keadaan Integration test untuk penyimpanan adapter, pembungkus plugin, dan kontrak IPC
• E2E test untuk beberapa perjalanan kritikal seperti login, alur pembelian, sinkronisasi, atau prompt pembaruan Koverasi bukanlah target, melainkan lampu sorot
• Laporan koverasi berguna ketika membantu Anda menemukan cabang yang belum diuji dalam logika penting. Namun, mereka menjadi berbahaya ketika tim mengejar persentase koverasi hanya untuk kepentingan sendiri. Validator login yang mempertimbangkan kasus edge memberikan nilai lebih daripada file yang tercover penuh dengan asertasi trivial. Hal ini terutama benar untuk input-heavy __CAPGO_KEEP_0__ seperti formulir, parser, logika tanggal, dan periksa akses. Jika tim Anda memperketat kualitas sekitar validasi UI berat, panduan ini tentang

menguasai validasi formulir frontend

merupakan tambahan yang baik untuk strategi testing level unit.

A login validator with thoughtful edge-case tests gives more value than a covered file full of trivial assertions. That’s especially true for input-heavy code such as forms, parsers, date logic, and permission checks. If your team is tightening quality around validation-heavy UI, this guide on Panduan ini membantu Anda memahami bagaimana mengembangkan aplikasi yang lebih baik dengan menggunakan Capgo. Dengan Capgo, Anda dapat mengembangkan aplikasi yang lebih baik dengan lebih cepat dan lebih efisien.

Capgo adalah platform pengembangan aplikasi yang memungkinkan Anda mengembangkan aplikasi dengan lebih cepat dan lebih efisien.

A suite yang dapat diandalkan harus memungkinkan Anda meredefinisikan bagian internal tanpa menulis ulang setengah dari tes. Cara termudah untuk mencapai hal ini adalah dengan mengasumsikan perilaku yang dapat diamati perilaku yang dapat diamati bukan detail implementasi.

Kasus penggunaan yang masih berlaku baik:

• Kondisi batas seperti input kosong, nilai null, jenis data yang tidak valid, dan string yang terlalu besar
• Hasil domain seperti “ditolak kembali karena izin yang hilang”
• Transisi keadaan seperti “mengidentifikasi update sebagai menunggu setelah metadata download diverifikasi”

Kasus penggunaan yang sering rusak:

• menginspeksi panggilan helper internal
• mengklaim metode privat berurutan
• mengganggu setiap lapisan dalam rantai panggilan

Bagi tim aplikasi yang membangun proses rilis yang disiplin, Capgo’s artikel tentang jaminan kualitas aplikasi bermanfaat karena menghubungkan pekerjaan tes dengan pipa rilis yang lebih luas.

Menguji untuk CI, Capacitor, dan Aplikasi Electron

Tes yang hanya berjalan di satu mesin pengembang bukanlah jaring pengaman. Itu adalah kebiasaan lokal.

CI mengubah tes unit kerja JavaScript menjadi infrastruktur tim. Setiap push, pull request, atau cabang rilis dapat menguji perintah yang sama dengan harapan yang sama. Konsistensi itu lebih penting lagi untuk Capacitor dan proyek Electron, di mana pergeseran lingkungan menyebabkan kegagalan yang halus.

Buat CI sebagai jalur eksekusi default

Paling tidak, CI Anda harus menginstal dependensi dan menjalankan suite unit pada setiap set perubahan. Simpan perintah identik dengan pengembangan lokal saat mungkin.

Alur kerja GitHub Actions yang sederhana dapat sekecil ini:

name: test

on: [push, pull_request]

jobs:
  unit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      - run: npm ci
      - run: npm test

Itu sudah cukup untuk menangkap impor yang rusak, asertasi yang gagal, dan asumsi platform yang tidak sengaja sebelum mereka mendarat di utama.

For tim mobile yang mengirimkan melalui pipa otomatis, Capgo memiliki panduan yang berguna untuk mengatur CI/CD untuk aplikasi Capacitor.

Menguji interaksi plugin Capacitor

Jalan yang salah untuk menguji unit Capacitor code adalah dengan menarik plugin native secara langsung ke dalam setiap layanan. Hal ini akan mengkoppel suite uji Anda dengan jembatan platform.

Polanya yang lebih baik adalah abstraksi tipis:

// deviceStorage.js
async function saveFile(filesystem, path, data) {
  return filesystem.writeFile({ path, data });
}

module.exports = { saveFile };

// draftService.js
async function persistDraft(storage, draft) {
  await storage.save('draft.json', JSON.stringify(draft));
  return { saved: true };
}

module.exports = { persistDraft };

// draftService.test.js
const { persistDraft } = require('./draftService');

test('persists a serialized draft', async () => {
  const storage = {
    save: jest.fn().mockResolvedValue(undefined)
  };

  const result = await persistDraft(storage, { title: 'Hello' });

  expect(result).toEqual({ saved: true });
});

Pemikiran yang sama berlaku untuk akses kamera, prompt biometrik, pendaftaran token push, dan status jaringan. Simpan panggilan plugin di adapter. Uji logika aplikasi terhadap interface yang Anda kendalikan.

Menguji Electron main renderer dan IPC code

Aplikasi Electron memiliki dua sambungan penting: proses utama code dan proses renderer codeTidak biarkan mereka kabur dalam uji coba.

Suatu pengaturan yang dapat diandalkan biasanya memisahkan:

• Uji unit Renderer untuk model tampilan, keadaan, pengaturan format, dan logika bisnis sisi UI
• Uji unit proses utama untuk menu, operasi file, dan keputusan siklus aplikasi
• Uji kontrak IPC untuk bentuk pesan dan respons yang diharapkan

Contoh wrapper IPC:

// ipcGateway.js
function sendSettings(ipcRenderer, payload) {
  ipcRenderer.send('settings:update', payload);
}

module.exports = { sendSettings };

// ipcGateway.test.js
const { sendSettings } = require('./ipcGateway');

test('sends settings update over ipc', () => {
  const ipcRenderer = { send: jest.fn() };

  sendSettings(ipcRenderer, { theme: 'dark' });

  expect(ipcRenderer.send).toHaveBeenCalledWith('settings:update', { theme: 'dark' });
});

Jika Anda kemudian mengubah implementasi internal dari satu bantuan ke bantuan lain, tes ini masih berlaku karena memverifikasi perilaku yang penting. Itu adalah standar yang Anda inginkan di desktop dan mobile code.

Tanya-Tanya yang Sering Diajukan Tentang Pengujian Satuan JavaScript

Apa perbedaan antara pengujian satuan integrasi dan E2E

A Unit Test Menguji satu bagian logika secara isolasi. Integration Test Menguji apakah beberapa komponen atau layanan bekerja bersama-sama dengan benar. End-to-End Test Menguji perjalanan pengguna melalui aplikasi yang berjalan.

Pakai unit test untuk kepercayaan cepat dalam aturan bisnis. Pakai integration test untuk celah seperti penyimpanan, wrapper plugin, dan IPC. Pakai E2E test dengan sedikit untuk alur kerja yang akan sangat terganggu jika rusak.

Apakah kita harus mencapai coverase penuh

Tidak. Coverase penuh dapat mendorong tim ke arah tes yang tidak berharga.

Coverase berguna ketika menunjukkan risiko code yang belum pernah digunakan. Tidak berguna ketika insinyur menambahkan asertasi dangkal hanya untuk memuaskan dashboard. Jika suite Anda sangat rapuh, coverase penuh tidak akan menyelamatkannya.

Bagaimana kita menambahkan tes ke kodebase yang sudah ada

Mulai dari tempat perubahan sudah terjadi. Jangan membuat tim beku dan mengumumkan rencana besar untuk merapikan strategi tes.

Sebuah urutan praktis seperti ini:

• Pertahankan code aktif terlebih dahulu dengan menambahkan tes ke modul yang Anda sentuh selama pekerjaan fitur atau perbaikan bug
• Ekstrak logika murni dari file-file yang sulit diuji sehingga aturan bisnis dapat diuji tanpa kebisingan framework atau runtime
• Tambahkan wrapper jahitan sekitar plugin native, klien jaringan, panggilan filesystem, dan IPC Electron
• Tolak pola yang rapuh ketika memperkenalkan mock. Panduan dari praktik terbaik pengujian JavaScript terutama berguna di sini karena menyoroti masalah yang sering terlewatkan yaitu over-mocking dan tes yang rapuh yang mengikuti

Tujuan bukanlah kesempurnaan segera. Itu adalah perbaikan yang stabil di tempat-tempat di mana regresi menghabiskan tim paling banyak.

Jika tim Anda mengirimkan produk Capacitor atau aplikasi Electron dan membutuhkan proses rilis yang lebih bersih seputar perubahan JavaScript, Capgo adalah salah satu pilihan untuk dilihat. Ini menyediakan pembaruan langsung untuk aplikasi CapacitorJS dan Electron, dengan kontrol peluncuran dan observabilitas, sehingga tim dapat memasangkan unit testing yang solid dengan jalur yang lebih aman untuk mengirimkan perubahan bundle web tanpa harus menunggu tinjauan toko untuk setiap perbaikan.